From jakob@crt.se Wed Jan 2 14:41:48 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA03072 for ; Wed, 2 Jan 2002 14:41:48 -0500 (EST) Received: from nic.crt.se (nic.crt.se [193.12.107.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA24081 for ; Wed, 2 Jan 2002 14:41:47 -0500 (EST) Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 32A3D5282; Wed, 2 Jan 2002 20:41:47 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 05F481DA4; Wed, 2 Jan 2002 20:41:46 +0100 (MET) Date: Wed, 2 Jan 2002 20:41:46 +0100 (CET) From: Jakob Schlyter To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] Key Distribution mail list (fwd) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: this might be interested to saag as well. also, I can add that the archive is availible as ftp://ftp.cafax.se/pub/archives/keydist.list jakob ---------- Forwarded message ---------- Date: Mon, 31 Dec 2001 14:17:38 -0500 From: Edward Lewis To: ietf@ietf.org Cc: lewis@tislabs.com Subject: Key Distribution mail list A new mail list has been set up to discuss the distribution of public keys across the network. Although preliminary discussions happened within the context of DNSSEC and the KEY RR, this background has proven to be insufficient to solve the problem of distributing keys. (The DNS history does *not* imply a DNS solution.) The mail list is still in its formation. We are in the process of defining scope and goals. If there is no archive yet, one will be started soon. The list is majordomo, called keydist@cafax.se. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. From rdd@cert.org Thu Jan 3 17:17:15 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA15413 for ; Thu, 3 Jan 2002 17:17:15 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA23467 for ; Thu, 3 Jan 2002 17:17:15 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.55) with ESMTP id RAA16097 for ; Thu, 3 Jan 2002 17:17:14 -0500 (EST) Received: from [10.20.10.44] (curium.yellow.cert.org [10.20.10.44]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id RAA28502; Thu, 3 Jan 2002 17:17:14 -0500 (EST) Date: Thu, 03 Jan 2002 17:16:46 -0500 From: Roman Danyliw To: saag@mit.edu Message-ID: <760892309.1010078206@[10.20.10.44]> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [saag] Incident Handling (INCH) BoF results Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Based on the interest expressed during the Incident Handling BoF at IETF 52, it was decided to create a new working group to investigate a standard format for representing incident data. The proposed charter can be found at: http://listserv.surfnet.nl/scripts/wa.exe?A2=ind02&L=inch&F=&S=&P=44 All discussion should be directed to the INCH mailing list: Post: inch@nic.surfnet.nl Archive: http://listserv.surfnet.nl/archives/inch.html Subscribe: send mail to listserv@nic.surfnet.nl with "subscribe inch " in the body cheers, Roman ====================================================================== Roman Danyliw | CERT Coordination Center | E-mail : rdd@cert.org Software Engineering Institute| Telephone: +1-412-268-7090 Carnegie Mellon University | (24-hour hotline) Pittsburgh PA 15213-3890 | Fax : +1-412-268-6989 http://www.cert.org/ | ======================================================================= From rja@inet.org Mon Jan 7 10:54:46 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA21488 for ; Mon, 7 Jan 2002 10:54:46 -0500 (EST) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA14056 for ; Mon, 7 Jan 2002 10:54:11 -0500 (EST) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 6222367103 for ; Mon, 7 Jan 2002 11:05:56 -0500 (EST) Message-Id: <5.1.0.14.2.20020107104143.01ecb4a0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 07 Jan 2002 10:43:19 -0500 To: saag@mit.edu From: RJ Atkinson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [saag] I-D ACTION: draft-le-mobileip-dh-01.txt Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: It probably wouldn't hurt for folks here to be aware of the draft announced below, if they weren't already aware of it. More review is usually better on key distribution/management proposals. >To: IETF-Announce: ; >Cc: mobile-ip@sunroof.eng.sun.com >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-le-mobileip-dh-01.txt >Date: Mon, 07 Jan 2002 09:07:23 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Dynamic Diffie Hellman based Key Distribution for > Mobile IPv6 > Author(s) : S. Faccin, F. Le > Filename : draft-le-mobileip-dh-01.txt > Pages : 9 > Date : 04-Jan-02 > >Mobile IP [1] requires several security associations: the Mobile Node >must share a security association with its Home agent and its >Correspondent Nodes to send the binding update; these messages must >be authenticated to prevent potential denial of service attacks [2]. >The MN and the Home Agent can have a static security association, >established at the configuration time, but the case of the >Correspondent Node is more complex since it cannot be assumed that >the MN and the CN have any pre-established security association. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-01.txt From raif@fl.net.au Sun Jan 13 17:33:52 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA02555 for ; Sun, 13 Jan 2002 17:33:50 -0500 (EST) Received: from int-mail.syd.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA26053 for ; Sun, 13 Jan 2002 17:33:49 -0500 (EST) Received: from solomon.fl.net.au (a5-p36.syd.fl.net.au [202.181.2.36]) by int-mail.syd.fl.net.au (Postfix) with ESMTP id E707316931; Mon, 14 Jan 2002 09:33:44 +1100 (EST) Message-Id: <5.0.0.25.1.20020113102736.00a75eb0@mail.syd.fl.net.au> X-Sender: raif@mail.syd.fl.net.au X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 14 Jan 2002 09:36:05 +1100 To: ietf-sasl@imc.org, saag@mit.edu From: "Raif S. Naffah" Cc: Keith Burdis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [saag] Algorithm Naming Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: We are faced with the problem of referencing algorithm names in our specification (SRP SASL mechanism). Related to algorithm naming, http://www.ietf.org/ID-nits.html states: Variant Algorithm Definitions If you specify multiple algorithms for a particular function: For example, if there are multiple compression algorithms, encryption algorithms, representation formats, etc., consider * A robust way to enumerate these, preferably with space for future assignments by the Internet Assigned Number Authority * Consider re-using an existing IANA registry instead of creating a new one, since this leads to less confusion between different registries that have similar items. Current IANA registries related to algorithm naming include: "Magic Numbers" for ISAKMP Protocol http://www.iana.org/assignments/isakmp-registry ONE TIME PASSWORD PARAMETERS http://www.iana.org/assignments/otp-parameters TELNET OPTIONS http://www.iana.org/assignments/telnet-options All of these are references for a certain specification and/or protocol. None of them provide a central reference that can be used by current or future IETF drafts/RFCs to unambiguously reference algorithms/primitives used within their specifications. Rather than create a new IANA registry solely for our specification, we propose that a new IANA registry be created to store security-related naming information that can be referenced by multiple specifications. This registry would hold information such as the names of message digest algorithms, integrity protection algorithms, ciphers, cipher modes of operations, key negotiation algorithms etc. (the name), as well as the reference to some published specifications of their design (the specification). The initiation of this process may be through an informational RFC that (a) describes the problem in more details, (b) gives an initial list of algorithm names, and (c) guidelines for registring more names with IANA. Keith Burdis and Raif S. Naffah From rja@inet.org Sun Jan 13 18:21:21 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA02883 for ; Sun, 13 Jan 2002 18:21:21 -0500 (EST) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA07327 for ; Sun, 13 Jan 2002 18:21:20 -0500 (EST) Received: from dragonfly.inet.org (unknown [10.30.20.241]) by gnat.inet.org (Postfix) with ESMTP id ABAF667104; Sun, 13 Jan 2002 18:34:40 -0500 (EST) Date: Sun, 13 Jan 2002 18:22:37 -0500 Subject: Re: [saag] Algorithm Naming Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: ietf-sasl@imc.org, saag@mit.edu, Keith Burdis To: "Raif S. Naffah" From: Ran Atkinson In-Reply-To: <5.0.0.25.1.20020113102736.00a75eb0@mail.syd.fl.net.au> Message-Id: <6E7E1277-087C-11D6-BB86-0003934A9252@inet.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Sunday, January 13, 2002, at 05:36 , Raif S. Naffah wrote: > > We are faced with the problem of referencing algorithm names in > our specification (SRP SASL mechanism). Related to algorithm > naming, http://www.ietf.org/ID-nits.html states: I have heard anecdotally that the US NIST (and possibly similar national standards bodies elsehwhere) maintains a list of algorithms (and associates them with ISO OIDs) that's public and extensible. Before IETF goes off to create another registry, ought we not check and see if there is one existant elsewhere that we could just reuse (e.g. US NIST, if suitable, or CSIRO, if the latter have one, or other such organisation) ? Ran From sob@newdev.harvard.edu Sun Jan 13 18:52:21 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA03151 for ; Sun, 13 Jan 2002 18:52:21 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA10781 for ; Sun, 13 Jan 2002 18:52:20 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g0DNpMn04510; Sun, 13 Jan 2002 18:51:22 -0500 (EST) Date: Sun, 13 Jan 2002 18:51:22 -0500 (EST) From: Scott Bradner Message-Id: <200201132351.g0DNpMn04510@newdev.harvard.edu> To: raif@fl.net.au, rja@inet.org Subject: Re: [saag] Algorithm Naming Cc: ietf-sasl@imc.org, keith@rucus.ru.ac.za, saag@mit.edu Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > Before IETF goes off to create another registry, ought we not > check and see if there is one existant elsewhere that we could > just reuse as long as entry to those lists is not unduely restricted Scott From rja@inet.org Sun Jan 13 19:02:22 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA03247 for ; Sun, 13 Jan 2002 19:02:22 -0500 (EST) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA07265 for ; Sun, 13 Jan 2002 19:02:22 -0500 (EST) Received: from dragonfly.inet.org (unknown [10.30.20.241]) by gnat.inet.org (Postfix) with ESMTP id 32C0E67104; Sun, 13 Jan 2002 19:15:43 -0500 (EST) Date: Sun, 13 Jan 2002 19:03:39 -0500 Subject: Re: [saag] Algorithm Naming Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: raif@fl.net.au, ietf-sasl@imc.org, keith@rucus.ru.ac.za, saag@mit.edu To: Scott Bradner From: Ran Atkinson In-Reply-To: <200201132351.g0DNpMn04510@newdev.harvard.edu> Message-Id: <2A043284-0882-11D6-BB86-0003934A9252@inet.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Sunday, January 13, 2002, at 06:51 , Scott Bradner wrote: >> Before IETF goes off to create another registry, ought we not >> check and see if there is one existant elsewhere that we could >> just reuse > > as long as entry to those lists is not unduely restricted AFAIK, the NIST list will accept virtually anything, including totally proprietary algorithms. Perhaps I'm misinformed... Ran From raif@fl.net.au Mon Jan 14 18:22:49 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA23823 for ; Mon, 14 Jan 2002 18:22:48 -0500 (EST) Received: from int-mail.syd.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA23749 for ; Mon, 14 Jan 2002 18:22:47 -0500 (EST) Received: from solomon.fl.net.au (a5-p50.syd.fl.net.au [202.181.2.50]) by int-mail.syd.fl.net.au (Postfix) with ESMTP id 2814616807; Tue, 15 Jan 2002 10:22:42 +1100 (EST) Message-Id: <5.0.0.25.1.20020115102058.00a40db0@mail.syd.fl.net.au> X-Sender: raif@mail.syd.fl.net.au X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 10:22:39 +1100 To: Ran Atkinson From: "Raif S. Naffah" Subject: Re: [saag] Algorithm Naming Cc: Scott Bradner , keith@rucus.ru.ac.za, saag@mit.edu In-Reply-To: <2A043284-0882-11D6-BB86-0003934A9252@inet.org> References: <200201132351.g0DNpMn04510@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 07:03 PM 1/13/02 -0500, Ran Atkinson wrote: >On Sunday, January 13, 2002, at 06:51 , Scott Bradner wrote: >>> Before IETF goes off to create another registry, ought we not >>>check and see if there is one existant elsewhere that we could >>>just reuse >> >>as long as entry to those lists is not unduely restricted > >AFAIK, the NIST list will accept virtually anything, including >totally proprietary algorithms. Perhaps I'm misinformed... could you be more specific as to where this NIST product is accessible from? a cursory search of didnt yield any useful information. TIA + cheers; rsn From kent@bbn.com Tue Jan 15 00:06:57 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id AAA29720 for ; Tue, 15 Jan 2002 00:06:56 -0500 (EST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA08227 for ; Tue, 15 Jan 2002 00:06:56 -0500 (EST) Received: from [128.33.238.36] (TC036.BBN.COM [128.33.238.36]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id AAA24140; Tue, 15 Jan 2002 00:06:34 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <5.0.0.25.1.20020113102736.00a75eb0@mail.syd.fl.net.au> References: <5.0.0.25.1.20020113102736.00a75eb0@mail.syd.fl.net.au> Date: Tue, 15 Jan 2002 00:05:30 -0500 To: "Raif S. Naffah" From: Stephen Kent Subject: Re: [saag] Algorithm Naming Cc: ietf-sasl@imc.org, saag@mit.edu, Keith Burdis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: A number of algorithms/modes are identified by OIDs, which are issued by various organizations under the overall ITU umbrella. I think IANA manages a tree arc for this purpose and we make use of it in several WGs already, e.g., S/MIME and PKIX. These WGs also make use of OIDs issued by other organizations (e.g., IEEE, RSA, NIST, DoD) who have arcs in the tree, to avoid duplication. Steve From raif@fl.net.au Tue Jan 15 17:49:13 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA18695 for ; Tue, 15 Jan 2002 17:49:12 -0500 (EST) Received: from int-mail.syd.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA26792 for ; Tue, 15 Jan 2002 17:49:11 -0500 (EST) Received: from solomon.fl.net.au (a4-p02.syd.fl.net.au [202.181.2.66]) by int-mail.syd.fl.net.au (Postfix) with ESMTP id DA7EA16815; Wed, 16 Jan 2002 09:49:07 +1100 (EST) Message-Id: <5.0.0.25.1.20020116094555.00a79220@mail.syd.fl.net.au> X-Sender: raif@mail.syd.fl.net.au X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 16 Jan 2002 09:49:05 +1100 To: Stephen Kent From: "Raif S. Naffah" Subject: Re: [saag] Algorithm Naming Cc: ietf-sasl@imc.org, saag@mit.edu, Keith Burdis In-Reply-To: <1011094495.3c4413dff2061@rucus.ru.ac.za> References: <5.0.0.25.1.20020113102736.00a75eb0@mail.syd.fl.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 01:34 PM 1/15/02 +0200, keith@rucus.ru.ac.za wrote: >Quoting Stephen Kent : > > > A number of algorithms/modes are identified by OIDs, which are issued > > by various organizations under the overall ITU umbrella. I think IANA > > manages a tree arc for this purpose and we make use of it in several > > WGs already, e.g., S/MIME and PKIX. These WGs also make use of OIDs > > issued by other organizations (e.g., IEEE, RSA, NIST, DoD) who have > > arcs in the tree, to avoid duplication. > >This is an interesting idea. Are there unique names associated with these >OIDs? > >While OIDs themselves are unique, we don't want to have to use: > > integrity=1.3.6.1.5.5.8.1.1 > >We'd rather use: > > integrity=HMAC-MD5 furthermore, OID-to-name associations lack the other aspect of the proposed registry: the specification of the algorithm itself; i.e. what (exactly) is referred to by the name. cheers; rsn From kent@bbn.com Tue Jan 15 21:09:34 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA22835 for ; Tue, 15 Jan 2002 21:09:34 -0500 (EST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA13116 for ; Tue, 15 Jan 2002 21:09:33 -0500 (EST) Received: from [128.33.238.105] (TC105.BBN.COM [128.33.238.105]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA02620; Tue, 15 Jan 2002 21:09:00 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <1011094495.3c4413dff2061@rucus.ru.ac.za> References: <5.0.0.25.1.20020113102736.00a75eb0@mail.syd.fl.net.au> <1011094495.3c4413dff2061@rucus.ru.ac.za> Date: Tue, 15 Jan 2002 12:11:17 -0500 To: keith@rucus.ru.ac.za From: Stephen Kent Subject: Re: [saag] Algorithm Naming Cc: "Raif S. Naffah" , ietf-sasl@imc.org, saag@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 1:34 PM +0200 1/15/02, keith@rucus.ru.ac.za wrote: >Quoting Stephen Kent : > >> A number of algorithms/modes are identified by OIDs, which are issued >> by various organizations under the overall ITU umbrella. I think IANA >> manages a tree arc for this purpose and we make use of it in several >> WGs already, e.g., S/MIME and PKIX. These WGs also make use of OIDs >> issued by other organizations (e.g., IEEE, RSA, NIST, DoD) who have >> arcs in the tree, to avoid duplication. > >This is an interesting idea. Are there unique names associated with >these OIDs? > >While OIDs themselves are unique, we don't want to have to use: > > integrity=1.3.6.1.5.5.8.1.1 > >We'd rather use: > > integrity=HMAC-MD5 > >> Steve > > - Keith There is a name associated with each registered algorithm, but it is not a requirement that the name be unique. also, in many instances, the form of the name will need to be more complex than your example, because of additional parameters of the algorithms. For example, HMAC-MD5 doesn't say whether the full 128-bit output is employed, or whether a truncated output is used, as in the case of current IPsec use in ESP and AH. I may have missed the usage context details that make use of OIDs impractical; could you restate the requirements re the form of the "name?" Steve From Linda.Millington@unilever.com Thu Jan 17 07:35:45 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id HAA27515 for ; Thu, 17 Jan 2002 07:35:45 -0500 (EST) Received: from tlr-na01.cp.u2809.unilever.com (inet02.unilever.com [204.110.170.5]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id HAA02635 for ; Thu, 17 Jan 2002 07:35:44 -0500 (EST) Received: from tru-001.cp.u2809.unilever.com by tlr-na01.cp.u2809.unilever.com with ESMTP for saag@MIT.EDU; Thu, 17 Jan 2002 07:32:38 -0500 Received: from [162.85.190.71] by tru-001.cp.u2809.unilever.com for saag@mit.edu; Thu, 17 Jan 2002 07:36:52 -0500 From: "Linda Millington" To: Date: Thu, 17 Jan 2002 07:36:00 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Subject: [saag] (no subject) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: From kent@bbn.com Thu Jan 17 21:27:56 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA12035 for ; Thu, 17 Jan 2002 21:27:56 -0500 (EST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA06202 for ; Thu, 17 Jan 2002 21:27:55 -0500 (EST) Received: from [128.33.238.69] (TC069.BBN.COM [128.33.238.69]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA23636; Thu, 17 Jan 2002 21:27:13 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> Date: Thu, 17 Jan 2002 20:33:07 -0500 To: "William Dixon" From: Stephen Kent Cc: , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [saag] RE: IP Storage and IPsec encapsulation Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 6:39 PM -0800 11/29/01, William Dixon wrote: >Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require >a transport layer interface definition for using IPSec security - in the >iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port >connection, deal with the binding of the authentication credential to >the traffic in the SA, allow/disallow iSCSI awareness of IKE SA >credentials, and IKE QM/IPSec SA state, and deal with the programmatic >policy addition to an otherwise admin defined SPD. > >Practically, shipping products that use IKE and IPSec in either mode for >TCP connection security means a well defined "policy" so that client >(iSCSI initiator) and server (iSCSI target) side products interoperate >with just credentials configured properly, ala web-based usage of SSL/TLS. Wiliam, I apologize that your message got buried in my inbox for about 65 weeks. I don't fully understand the issues you are raising here, perhaps because of your extremely concise exposition in the first paragraph :-). IPsec already knows how to manage SAs at the granularity of TCP port pairs. IPsec does not say where the credentials used by IKE come from; a TLI could provide them. you have not made clear what features of the IPsec specs preclude what you want to do. of course, I'm more interested in that what needs to be accomplished, and why, rather that how you would like to accomplish it. BTW, it's IPsec, not IPSec. Steve From keith@rucus.ru.ac.za Tue Jan 15 06:35:01 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA06125 for ; Tue, 15 Jan 2002 06:35:01 -0500 (EST) From: keith@rucus.ru.ac.za Received: from rucus.ru.ac.za (server.rucus.ru.ac.za [146.231.115.1]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id GAA02607 for ; Tue, 15 Jan 2002 06:34:59 -0500 (EST) Received: (qmail 51902 invoked by uid 65532); 15 Jan 2002 11:34:56 -0000 Received: from tcen-prxy-array.telkom.co.za ( [tcen-prxy-array.telkom.co.za]) as user keith@rucus.ru.ac.za by rucus.ru.ac.za with HTTP; Tue, 15 Jan 2002 13:34:55 +0200 Message-ID: <1011094495.3c4413dff2061@rucus.ru.ac.za> Date: Tue, 15 Jan 2002 13:34:55 +0200 To: Stephen Kent Cc: "Raif S. Naffah" , ietf-sasl@imc.org, saag@mit.edu Subject: Re: [saag] Algorithm Naming References: <5.0.0.25.1.20020113102736.00a75eb0@mail.syd.fl.net.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Quoting Stephen Kent : > A number of algorithms/modes are identified by OIDs, which are issued > by various organizations under the overall ITU umbrella. I think IANA > manages a tree arc for this purpose and we make use of it in several > WGs already, e.g., S/MIME and PKIX. These WGs also make use of OIDs > issued by other organizations (e.g., IEEE, RSA, NIST, DoD) who have > arcs in the tree, to avoid duplication. This is an interesting idea. Are there unique names associated with these OIDs? While OIDs themselves are unique, we don't want to have to use: integrity=1.3.6.1.5.5.8.1.1 We'd rather use: integrity=HMAC-MD5 > Steve - Keith From uri@bell-labs.com Fri Jan 18 12:13:13 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA26531 for ; Fri, 18 Jan 2002 12:13:13 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA06165 for ; Fri, 18 Jan 2002 12:13:13 -0500 (EST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0IHD8c17479 for ; Fri, 18 Jan 2002 12:13:12 -0500 (EST) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA28237; Fri, 18 Jan 2002 12:13:04 -0500 (EST) Cc: saag@mit.edu Received: from bell-labs.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA28224; Fri, 18 Jan 2002 12:13:01 -0500 (EST) Message-ID: <3C4856B4.4B75B9F8@bell-labs.com> Date: Fri, 18 Jan 2002 12:09:09 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: keith@rucus.ru.ac.za Original-CC: saag@mit.edu Subject: Re: [saag] Algorithm Naming References: <5.0.0.25.1.20020113102736.00a75eb0@mail.syd.fl.net.au> <1011094495.3c4413dff2061@rucus.ru.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: keith@rucus.ru.ac.za wrote: > > A number of algorithms/modes are identified by OIDs..... > > and we make use of it in several WGs already...... > > This is an interesting idea. Are there unique names associated with these OIDs? > While OIDs themselves are unique, we don't want to have to use: > integrity=1.3.6.1.5.5.8.1.1 > We'd rather use: > integrity=HMAC-MD5 It would probably be like integrity.hmac.md5 Each number of the OID can (and usually does) have its own name. -- Regards, Uri. -=-=-<>-=-=- From enzo@ocean-logic.com Sat Feb 2 00:44:21 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id AAA16220 for ; Sat, 2 Feb 2002 00:44:21 -0500 (EST) Received: from mail004.syd.optusnet.com.au (mail004.syd.optusnet.com.au [203.2.75.228]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA07993 for ; Sat, 2 Feb 2002 00:44:20 -0500 (EST) Received: from co3001263a (c40190.belrs1.nsw.optusnet.com.au [203.164.13.82]) by mail004.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id g125iFR25057; Sat, 2 Feb 2002 16:44:15 +1100 From: "Vincenzo Liguori" To: Cc: Date: Sat, 2 Feb 2002 16:44:54 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [saag] AES Counter Mode Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Dear Mr. McGrew, My name is Vincenzo Liguori and I am the director of Ocean logic Pty Ltd, a small company that offers soft core IPs for VLSI implementation. Recently, a customer of ours has made some enquiries regarding AES Counter Mode and we might to be add this mode to our AES core family. After a short search with Google, I have found your specification on line : http://www.ietf.org/internet-drafts/draft-mcgrew-saag-icm-00.txt My questions are: Is the draft likely to change before approval ? When is approval likely to be given ? Is there any reference C code available ? Thank you very much in advance. Regards, Vincenzo Liguori ------------------------------------------------------------------ Vincenzo Liguori Ocean Logic Pty Ltd PO BOX 768 Manly NSW 1655 Australia Ph : +61-2-99054152 Fax : +61-2-99050921 Email : enzo@ocean-logic.com WWW : http://www.ocean-logic.com From delder@ibigroup.com Wed Feb 6 06:51:05 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA17226 for ; Wed, 6 Feb 2002 06:51:04 -0500 (EST) Received: from mail.freeola.enta.net (mail.freeola.enta.net [195.74.96.155]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id GAA00586 for ; Wed, 6 Feb 2002 06:51:02 -0500 (EST) Received: (from root@localhost) by mail.freeola.enta.net (8.11.1/8.11.1) id g16BrJr32767 for saag@mit.edu; Wed, 6 Feb 2002 11:53:19 GMT (envelope-from delder@ibigroup.com) Received: from ibi025 ([195.74.112.218]) by mail.freeola.enta.net (8.11.1/8.11.1) with SMTP id g16BrGS32714 for ; Wed, 6 Feb 2002 11:53:17 GMT (envelope-from delder@ibigroup.com) Message-ID: <01eb01c1af04$ae1f4760$18bb80c2@carlbro.co.uk> Reply-To: "Duncan Elder - IBI Group" From: "Duncan Elder - IBI Group" To: Date: Wed, 6 Feb 2002 11:26:59 -0000 Organization: IBI Group MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CC_01C1AF01.30B3C380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [saag] (no subject) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_01CC_01C1AF01.30B3C380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to get hold of a standards document for Web Server Security = (Specifically NT/IIS)? Can you help? Thanks in advance Duncan -------------------------- Duncan Elder IBI Group 4 Lynedoch Place Glasgow G3 6AB Tel.: +44 (0)141 331 2525 Fax.: +44 (0)141 333 1033 Email: delder@ibigroup.com IBI Group do not accept legal responsibility for the contents of this message unless confirmed in writing by an authorised signatory. Any = views or opinions presented are solely those of the author and do not = necessarily represent those of IBI. Access by the intended recipient only is authorised. Any review, retransmission, dissemination or other use of, = or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. NOTE: This e-mail message and attachments may contain privileged and confidential information. If you have received this message in error, please immediately notify the sender and delete this e-mail message. ------=_NextPart_000_01CC_01C1AF01.30B3C380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am trying to get hold of a standards = document=20 for Web Server Security (Specifically NT/IIS)? Can you = help?
 
Thanks in advance
 
Duncan
 
 
--------------------------
Duncan = Elder
IBI=20 Group
4 Lynedoch Place
Glasgow  G3 6AB
Tel.:  +44 = (0)141 331=20 2525
Fax.:  +44 (0)141 333 1033
Email: delder@ibigroup.com
 

IBI Group do not accept legal responsibility for the contents = of=20 this
message unless confirmed in writing by an authorised = signatory. =20 Any views
or opinions presented are solely those of the author and do = not=20 necessarily
represent those of IBI. Access by the intended recipient = only=20 is
authorised. Any review, retransmission, dissemination or other use = of,=20 or
taking of any action in reliance upon, this information by persons = or
entities other than the intended recipient is prohibited.
 
NOTE: This e-mail message and attachments may contain privileged=20 and
confidential information.  If you have received this message = in=20 error,
please immediately notify the sender and delete this e-mail=20 message.
 
 
------=_NextPart_000_01CC_01C1AF01.30B3C380-- From mar_kub@hotmail.com Fri Feb 8 15:55:46 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA25131 for ; Fri, 8 Feb 2002 15:55:46 -0500 (EST) Received: from M5Mailer (CPE00e0290a037c.cpe.net.cable.rogers.com [24.112.151.70]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id PAA15517 for ; Fri, 8 Feb 2002 15:55:44 -0500 (EST) From: "Gelmondo Rodrigas" To: saag@mit.edu Date: Fri, 08 Feb 2002 15:44:17 -0500 X-Mailer: Mach5 Mailer-2.50 PID{c8ea4ab9-47eb-461a-9ecf-71e0638a0731} RC{} Reply-To: mar_kub@hotmail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----000000000000000000000" Message-ID: <200228204417510VXMRCEARNAET@M5Mailer> Subject: [saag] crypto web site Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: ------000000000000000000000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, While browsing the web on 1/26/2002, I came accross your address (saag@mit.edu) on a very interesting web page http://web.mit.edu/ network/ietf/sa/ titled IETF SECURITY AREA. I know you will be glad to find out about a related crypto/security service CryptoHeaven. Have a look at the web site (.com), its a great site with lots of info... Thanks, Gelmondo ------000000000000000000000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello,

While browsing the web on 1/26/2002, I came accross your address (saag@mit.edu) on a very interesting web page http://web.mit.edu/network/ietf/sa/ titled IETF SECURITY AREA.

I know you will be glad to find out about a related crypto/security service CryptoHeaven. Have a look at the web site (.com), its a great site with lots of info...

Thanks,
Gelmondo ------000000000000000000000-- From pekkas@netcore.fi Sat Feb 9 11:51:26 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA04027 for ; Sat, 9 Feb 2002 11:51:26 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08243 for ; Sat, 9 Feb 2002 11:51:25 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g19GpLs18953; Sat, 9 Feb 2002 18:51:21 +0200 Date: Sat, 9 Feb 2002 18:51:21 +0200 (EET) From: Pekka Savola To: Duncan Elder - IBI Group cc: saag@mit.edu Subject: Re: [saag] (no subject) In-Reply-To: <01eb01c1af04$ae1f4760$18bb80c2@carlbro.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Wed, 6 Feb 2002, Duncan Elder - IBI Group wrote: > I am trying to get hold of a standards document for Web Server Security (Specifically NT/IIS)? Can you help? I don't think it's proper to mention security and NT/IIS in the same sentence. But really, IETF (or SAAG) is no place for defining how to secure systems. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From coley@linus.mitre.org Sat Feb 9 18:40:47 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA06574 for ; Sat, 9 Feb 2002 18:40:47 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA01951 for ; Sat, 9 Feb 2002 18:40:47 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g19Nek820790 for ; Sat, 9 Feb 2002 18:40:46 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g19Nejk16908 for ; Sat, 9 Feb 2002 18:40:45 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id SAA20813; Sat, 9 Feb 2002 18:40:45 -0500 (EST) Date: Sat, 9 Feb 2002 18:40:45 -0500 (EST) Message-Id: <200202092340.SAA20813@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: Re: [saag] (no subject) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I will send some pointers to the person who requested the information. - Steve From coley@linus.mitre.org Mon Feb 18 16:03:21 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA18514 for ; Mon, 18 Feb 2002 16:03:21 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA05531 for ; Mon, 18 Feb 2002 16:03:20 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1IL3K805680; Mon, 18 Feb 2002 16:03:20 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1IL3Ik26486; Mon, 18 Feb 2002 16:03:18 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id QAA10850; Mon, 18 Feb 2002 16:03:18 -0500 (EST) Date: Mon, 18 Feb 2002 16:03:18 -0500 (EST) Message-Id: <200202182103.QAA10850@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu CC: cwysopal@atstake.com Subject: [saag] I-D released: Responsible Vulnerability Disclosure Process Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hello, In December 2001, Chris Wysopal and I attempted to submit a document on responsible disclosure as an Internet-Draft. However, because we did not follow the normal IETF protocols, and we submitted it during the IETF meeting, and some miscommunications occurred, our document was left with an uncertain status. We have since made an independent submission and it is now an Internet-Draft: http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt This I-D only has some minor differences from the one we sent in December, specifically fixed typos, a new abstract, and some minor format changes. As suggested to us by Marcus Leech, this draft can be discussed on the SAAG mailing list. When we publicize this document to the information security industry, we intend to include information for how people can join the SAAG mailing list in order to provide comments that are visible to the IETF. I'm noting this because there is a possibility that this I-D could generate an increase in traffic to this list. Regards, Steve Christey Lead INFOSEC Engineer The MITRE Corporation Chris Wysopal Director of Research and Development @stake, Inc. From randy@psg.com Mon Feb 18 16:30:03 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA18793 for ; Mon, 18 Feb 2002 16:30:03 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA12450 for ; Mon, 18 Feb 2002 16:30:02 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16cvMB-000EGg-00; Mon, 18 Feb 2002 13:29:55 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Steven M. Christey" Cc: saag@mit.edu, cwysopal@atstake.com Subject: Re: [saag] I-D released: Responsible Vulnerability Disclosure Process References: <200202182103.QAA10850@linus.mitre.org> Message-Id: Date: Mon, 18 Feb 2002 13:29:55 -0800 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > As suggested to us by Marcus Leech, this draft can be discussed on the > SAAG mailing list. When we publicize this document to the information > security industry, we intend to include information for how people can > join the SAAG mailing list in order to provide comments that are > visible to the IETF. I'm noting this because there is a possibility > that this I-D could generate an increase in traffic to this list. if so, could someone start a new saag list, please? From steve@stevecrocker.com Mon Feb 18 16:38:29 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA18932 for ; Mon, 18 Feb 2002 16:38:29 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA14758 for ; Mon, 18 Feb 2002 16:38:28 -0500 (EST) Received: from [66.92.150.17] (HELO SDC3) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with SMTP id 2792274; Mon, 18 Feb 2002 16:38:27 -0500 From: "Steve Crocker" To: "Randy Bush" , "Steven M. Christey" Cc: , Subject: RE: [saag] I-D released: Responsible Vulnerability Disclosure Process Date: Mon, 18 Feb 2002 16:36:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steven, There should be a distinct mailing list for any extended, in depth discussion of this material, not the SAAG mailing list. Your document presents a slightly new challenge because it's not a protocol and doesn't fit neatly into any of the working groups, but that's easily fixed. If there isn't an existing working group which provides a natural home, start one up. Steve > -----Original Message----- > From: saag-admin@mit.edu [mailto:saag-admin@mit.edu]On Behalf Of Randy > Bush > Sent: Monday, February 18, 2002 4:30 PM > To: Steven M. Christey > Cc: saag@mit.edu; cwysopal@atstake.com > Subject: Re: [saag] I-D released: Responsible Vulnerability Disclosure > Process > > > > As suggested to us by Marcus Leech, this draft can be discussed on the > > SAAG mailing list. When we publicize this document to the information > > security industry, we intend to include information for how people can > > join the SAAG mailing list in order to provide comments that are > > visible to the IETF. I'm noting this because there is a possibility > > that this I-D could generate an increase in traffic to this list. > > if so, could someone start a new saag list, please? > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag From jis@MIT.EDU Mon Feb 18 17:33:20 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA19612; Mon, 18 Feb 2002 17:33:20 -0500 (EST) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA03625; Mon, 18 Feb 2002 17:33:20 -0500 (EST) Received: (from jis@localhost) by jis.mit.edu (8.9.1b+Sun/8.9.3) id RAA19564; Mon, 18 Feb 2002 17:30:52 -0500 (EST) X-Authentication-Warning: jis.mit.edu: jis set sender to jis@mit.edu using -f Date: Mon, 18 Feb 2002 17:30:52 -0500 From: "Jeffrey I. Schiller" To: Steve Crocker Cc: Randy Bush , "Steven M. Christey" , saag@mit.edu, cwysopal@atstake.com Subject: Re: [saag] I-D released: Responsible Vulnerability Disclosure Process Message-ID: <20020218173052.K6389@mit.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from steve@stevecrocker.com on Mon, Feb 18, 2002 at 04:36:48PM -0500 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Actually it was my suggestion to use the SAAG list. If indeed a substantial discussion ensues that isn't of interest to most SAAG subscribers, then I can setup a new mailing list for it. -Jeff On Mon, Feb 18, 2002 at 04:36:48PM -0500, Steve Crocker wrote: > Steven, > > There should be a distinct mailing list for any extended, in depth > discussion of this material, not the SAAG mailing list. Your document > presents a slightly new challenge because it's not a protocol and doesn't > fit neatly into any of the working groups, but that's easily fixed. If > there isn't an existing working group which provides a natural home, start > one up. > > Steve > > > -----Original Message----- > > From: saag-admin@mit.edu [mailto:saag-admin@mit.edu]On Behalf Of Randy > > Bush > > Sent: Monday, February 18, 2002 4:30 PM > > To: Steven M. Christey > > Cc: saag@mit.edu; cwysopal@atstake.com > > Subject: Re: [saag] I-D released: Responsible Vulnerability Disclosure > > Process > > > > > > > As suggested to us by Marcus Leech, this draft can be discussed on the > > > SAAG mailing list. When we publicize this document to the information > > > security industry, we intend to include information for how people can > > > join the SAAG mailing list in order to provide comments that are > > > visible to the IETF. I'm noting this because there is a possibility > > > that this I-D could generate an increase in traffic to this list. > > > > if so, could someone start a new saag list, please? > > > > > > _______________________________________________ > > saag mailing list > > saag@mit.edu > > http://jis.mit.edu/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag From jericho@attrition.org Mon Feb 18 18:25:48 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA20241 for ; Mon, 18 Feb 2002 18:25:48 -0500 (EST) Received: from forced.attrition.org ([63.105.33.158]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA10258 for ; Mon, 18 Feb 2002 18:25:47 -0500 (EST) Received: from localhost (jericho@localhost) by forced.attrition.org (8.9.3/3.8.9) with SMTP id SAA25293 for ; Mon, 18 Feb 2002 18:28:57 -0500 Date: Mon, 18 Feb 2002 18:28:57 -0500 (EST) From: security curmudgeon To: saag@mit.edu Message-ID: X-NoSpam: You do not have consent to spam me. X-Attrition: Attrition is only good when forced. http://www.attrition.org X-Copyright: This e-mail copyright 2002 by jericho@attrition.org where applicable X-Encryption: rot26 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] Re: Responsible Disclosure finally an Internet-Draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I made the following comments on another list. Weld asked that I cross post the comments to SAAG. Random comments and feedback: > The purpose of this document is to describe best practices for a > responsible disclosure process that involves vulnerability reporters, > product vendors or maintainers, third parties, the security > community, and ultimately customers and users. > > The actual draft is at: > > http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt 4) If the Vendor can control the e-mail addresses that it uses (e.g., it has its own domain name), then the Vendor SHOULD define and publish the "secalert" alias for use in vulnerability notification. Rationale: Currently, Vendors use a variety of aliases for notification, including "security-alert," "security," and "support." Some Vendors may use the "security" alias for physical security facilities. The "security" alias is also defined in RFC2142 for use in incident handling. The "security-alert" alias is longer than 8 characters and contains a dash, which could make it more difficult to use or locate in search engines. The "secalert" alias is not commonly used at this time, and as such it does not have the types of issues that some commonly-used aliases have. I disagree here. Two points why really. First, if vendors already have a 'security' alias, then they probably have someone watching it already. Vendors don't want to staff more people for this, that costs money. Suggesting and hinting that they use existing staff watching that alias is more friendly to their bottom line. Their staff can easily tell if it is a physical security or software security problem, and forward/respond to it accordingly. Second, when most people think of "security problems" and mailing a vendor, the word 'security' is first thing into their mind. Actually a third thing comes to mind.. don't a few vendors use "secalert" already for distribution of their advisories? 2) If the Reporter is unable to notify the Vendor, then the Reporter SHOULD ask a Coordinator to notify the Vendor. The Reporter SHOULD provide the Coordinator with a list of contacts or mechanisms that were used to attempt to notify the Vendor. I'm not following the 'coordinator' here. As defined, it sounds like an example of this would be having Al Huger, Elias Levy, Russ Cooper or someone in a position like that. If lowly jericho w/ attrition can't reach a vendor, and I know that one of the three names I just listed has a source there, that would fit the description above. That said, and if that is the case, I think you should add a caveat here or in the definition of a 'coordinator' that explicity states they can not profit or benefit from my using them to practice responsible disclosure. It is easy for someone in a position like that to abuse the information and release it to their friends or some other group of people, even make money off it, all without my knowledge. In short, they would be abusing the system and abusing their status. I realize it would be difficult to detect such a thing, but we know that it happens, and we know that it is sometimes discovered. If it is explicitly stated, individuals abusing such a position can't later say "i didn't realize this was wrong to do" etc. Following up on that last quoted point: Rationale: a Coordinator may appear more credible than the Reporter, or have a previously established relationship with the Vendor. The Reporter may be prohibited from disclosing the vulnerability directly to the Vendor. Note: the Coordinator will not necessarily have a different way of reaching the Vendor than the Reporter does. I feel the wording here is bad. This seems to suggest/encourage the idea that vendors can/should see one vulnerability reporter as less credible than another. ANYONE following these steps, be it "Joe Consultant" or "Lord Viper Scorpion" should be given equal respect and credibility until they do something that betrays that credibility. Think about it, you are implying/suggesting that one person should or does have different pull with a vendor for an arbitrary reason, despite explicitly stating otherwise in another section of the document. 4) Within 10 days of initial notification, the Vendor's Security Response Capability SHOULD provide a clear response to the Reporter and any involved Coordinators. Perhaps suggest what this response should include. This wording suggests a vendor can reply "we received your email" within 10 days and that is good. To me that is not a 'clear response'. Correct me if I am wrong, but i imagine you may mean a clear response is "we can reproduce the problem and are working on a fix" or something more descript. 4) The Vendor SHOULD examine its product to ensure that it is free of other problems that are similar to the reported vulnerability. Rationale: some Vendors reproduce and resolve the specific issue that is identified by the Reporter without extending their analysis to see if similar mistakes were made elsewhere in the product. The Reporter, others in the Security Community, or hackers may conduct follow-on research to find these other vulnerabilities. This can result in a cycle in which vulnerabilities are discovered and patched so often that it becomes difficult for customers to manage the volume of resolutions that they need to apply. This is a really good point, but one that may need some clarification or vendors are likely to dismiss it. Weld reports a buffer overflow to Microsoft. By the above paragraph, they are then suggested to examine its product to ensure they are free of other problems of a similar nature.. ie: buffer overflows. This turns into a full code audit. While we all want that to happen, the odds of MS doing that in response to a single vulnerability is unlikely. Perhaps some wording to address that and let vendors know that it is a big task etc. More importantly, what if they do find more vulns, then what? I think this is a great place to push vendors to report those bugs (after they are fixed), or at least move away from the silent patching that goes on. This can also prove to be very valuable to other security consultants in some cases. Imagine this scenario: Microsoft releases NewProductA. Weld finds a vulnerability in Function1 and reports it. During the mail exchange, RFP finds a vulnerability in Function2. As MS/Weld communicate, they follow this draft and audit their code and find the same vulnerability that RFP has found. If they quietly fix it, RFP may work on details for a lot of time when it isn't needed. If Microsoft patches it and releases that info along with the first, or in a seperate advisory, it could save responsible discoverers valuable time/resources. 5) The Vendor MUST consult with the Reporter and involved Coordinators when more information or analysis is needed. 6) The Vendor SHOULD provide status updates to the Reporter and any involved Coordinators every 7 days. The Vendor MAY negotiate with the parties for less frequent updates. 7) The Vendor MUST notify the Reporter and any involved Coordinators when the Vendor is able to reproduce the vulnerability. This just occured to me, as an add on to an earlier comment I made in this mail. Each step above you explicitly state that the vendor should mail the Reporter AND the Coordinator. Why? The Coordinator's role is to help faciliate communication between a Reporter and Vendor that are having difficulty finding a way to communicate. Once that line of communication has been established, why does the Coordinator need to be contacted for each step like this? In my example above where I express concern about a Coordinator using my information for his own gain, this does nothing but facilitates that. If I voluntarily choose to share the updates from the vendor with my coordinator, that is fine. I don't feel it should be RFC mandated that the vendor keep the coordinator updated on the same schedule as the reporter. 10) If the Vendor is aware of other vendors that share the same codebase as the affected product, then the Vendor MUST either (1) notify those vendors, or (2) notify a Coordinator that other Vendors may be affected by the reported vulnerability. This is not necessarily productive or ethical I don't think. If I report a buffer overflow in an RPC daemon to Sun, and they know right off that is very likely the same codebase as HP, AIX, Irix, Linux, etc, it should be immediately reported to other vendors. This could happen one of two ways. First, they could contact them directly, but could cause problems like we saw with Linux vendors pre-empting each other. Second, they could express the concerns to the Reporter and let them contact other vendors as they see fit. The draft currently reads that after 30 days of sitting on vulnerability information, they must share it with other vendors if it affects them. That isn't very cooperative and doesn't help patch the vuln quickly. In fact, vendors can use this as an extension method! After 30 days, they report it to another vendor, and begin the 30 day window again with the new vendor. That gives them an additional 30 days to fix their own system. If this is a unix bug that goes across 5 platforms, now we have up to 150 day window for the vendor to procrastinate. Worse, it is being set up for one of the companies to pre-empt another vendor. 6) If the Vendor is unresponsive or disagrees with the Reporter's findings, then the Reporter SHOULD involve a Coordinator. What if the Reporter has no Coordinator, and does not know who to consult to find one? From pete.chown@skygate.co.uk Tue Feb 19 05:20:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id FAA26712 for ; Tue, 19 Feb 2002 05:20:18 -0500 (EST) Received: from lion.skygate.co.uk (lion.skygate.co.uk [212.134.128.34]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id FAA03062 for ; Tue, 19 Feb 2002 05:20:17 -0500 (EST) Received: from hyena.skygate.co.uk ([10.0.0.2]) by lion.skygate.co.uk with esmtp (Exim 3.33 #1) id 16d7Ng-000633-00 for saag@mit.edu; Tue, 19 Feb 2002 10:20:16 +0000 Received: from localhost ([127.0.0.1]) by hyena.skygate.co.uk with esmtp (Exim 3.33 #1) id 16d7Ng-0006b4-00 for saag@mit.edu; Tue, 19 Feb 2002 10:20:16 +0000 Subject: Re: [saag] I-D released: Responsible Vulnerability Disclosure Process From: Pete Chown To: saag@mit.edu In-Reply-To: <200202182103.QAA10850@linus.mitre.org> References: <200202182103.QAA10850@linus.mitre.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Feb 2002 10:20:15 +0000 Message-Id: <1014114016.9998.19.camel@hyena.skygate.co.uk> Mime-Version: 1.0 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steven M. Christey wrote: > This I-D only has some minor differences from the one we sent in > December, specifically fixed typos, a new abstract, and some minor > format changes. I read through the original document back in December and posted some comments on the saag list. Did you get these okay, and if so what did you think? -- Pete From coley@linus.mitre.org Tue Feb 19 18:19:58 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA06039 for ; Tue, 19 Feb 2002 18:19:58 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA10637 for ; Tue, 19 Feb 2002 18:19:58 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1JNJv812352; Tue, 19 Feb 2002 18:19:57 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1JNJuk15581; Tue, 19 Feb 2002 18:19:56 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id SAA20802; Tue, 19 Feb 2002 18:19:45 -0500 (EST) Date: Tue, 19 Feb 2002 18:19:45 -0500 (EST) Message-Id: <200202192319.SAA20802@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: jericho@attrition.org CC: saag@mit.edu Subject: [saag] Re: Responsible Disclosure finally an Internet-Draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: security curmudgeon said: >> 4) If the Vendor can control the e-mail addresses that it uses (e.g., >> it has its own domain name), then the Vendor SHOULD define and >> publish the "secalert" alias for use in vulnerability notification. >I disagree here. Two points why really. First, if vendors already have >a 'security' alias, then they probably have someone watching it >already. Vendors don't want to staff more people for this, that costs >money. The thinking is to have a single alias that all vendors use, so that vulnerability reporters don't have to wade through complicated web sites or support forms. >Suggesting and hinting that they use existing staff watching that >alias is more friendly to their bottom line. Their staff can easily >tell if it is a physical security or software security problem, and >forward/respond to it accordingly. That's an interesting point. However, this still could require a process change on the part of vendors, i.e. training their physical security people to recognize security reports. (On the other hand, so might a secalert alias, especially for Vendors who haven't established a Security Response Capability yet). Vendors may have difficulty getting their *tech support* to recognize a vulnerability report. (This just happened to me a few days ago; tech support clearly didn't understand why I cared about a reported weak encryption vulnerability in their product because "our customers haven't complained about it.") There's also the possible overlap with recommendations of another BCP in using "security" for reporting incidents, which could produce extra traffic that is resource-intensive for the Vendor's teams to sort out. >Second, when most people think of "security problems" and mailing a >vendor, the word 'security' is first thing into their mind. Agreed. There's nothing in this I-D that prevents a Vendor from having a security alias as well, but it tries to recognize that some Vendors already use the security alias for something else. >Actually a third thing comes to mind.. don't a few vendors use >"secalert" already for distribution of their advisories? I did a web search when trying to think of a "neutral" but security-related aliases. The closest alias I could find for secalert is Oracle's "secalert_us" alias. A fresh search of Google shows that Cray may already use this address; other matches on "secalert" are directory or URL names. One possible benefit of the secalert address is that it "spreads the pain" to all Vendors, while allowing them to make clear that they are following "best practices." Some might argue that this recommendation to create a *new* secalert alias is not "best practice," but there are issues of overlap with the current "common practice" of using the security alias, and the security alias is not universally used by Vendors. >> 2) If the Reporter is unable to notify the Vendor, then the Reporter >> SHOULD ask a Coordinator to notify the Vendor. The Reporter SHOULD >> provide the Coordinator with a list of contacts or mechanisms that >> were used to attempt to notify the Vendor. > >I'm not following the 'coordinator' here. As defined, it sounds like an >example of this would be having Al Huger, Elias Levy, Russ Cooper or >someone in a position like that. It's an attempt to recognize that there are individuals or organizations who act as intermediaries, such as Russ Cooper, CERT/CC, and SecurityFocus (whether Levy, Huger, or their VulnHelp service). However, I imagine that there are others who can (or do) play this role, especially with the growth of ISACs and other information-sharing partnerships. >If lowly jericho w/ attrition can't reach a vendor, and I know that >one of the three names I just listed has a source there, that would >fit the description above. The thinking is that besides a better contact list, Coordinators may have more "name recognition" or apparent credibility than "lowly" Jericho from attrition.org ;-) Even Rain Forest Puppy, one of the most prominent vulnerability researchers, is not known to most vendors, and he sometimes has issues with getting vendors to take his vulnerability reports seriously, possibly as a result of his nym. The problem is worse when Jane Doe or Joe Schmoe try to report an issue. >I think you should add a caveat here or in the definition of a >'coordinator' that explicity states they can not profit or benefit >from my using them to practice responsible disclosure. It is easy for >someone in a position like that to abuse the information and release >it to their friends or some other group of people, even make money off >it, all without my knowledge. In short, they would be abusing the >system and abusing their status. Great point, but how does one define "benefit?" Coordinators may obtain credibility for this work, which they might then highlight for marketing or other purposes. I'm not sure where this recommendation would be placed in the current I-D, as it's laid out. It applies to most phases of the disclosure process. > Rationale: a Coordinator may appear more credible than the Reporter, > or have a previously established relationship with the Vendor. The > Reporter may be prohibited from disclosing the vulnerability directly > to the Vendor. > >I feel the wording here is bad. This seems to suggest/encourage the >idea that vendors can/should see one vulnerability reporter as less >credible than another. ANYONE following these steps, be it "Joe >Consultant" or "Lord Viper Scorpion" should be given equal respect and >credibility until they do something that betrays that credibility. ["Lord Viper Scorpion?" Is that a Jon Stewart/Daily Show reference?] A larger problem is that without peer review or "certification" for reporters, it's difficult for a vendor to tell about someone's credibility at face value. (Hopefully the Sardonix source-auditing project will be fruitful in exploring this question.) This becomes a problem for vendors who receive a number of vulnerability reports, many of which may be rediscoveries of old issues, poorly worded, or lacking important details for replication. Reporter credibility may help vendors to conduct "triage" on vulnerability reports... as well as better information in the initial vulnerability reports (but that's a separate document). This I-D is also trying to address vendors who *don't* give sufficient credibility to all reporters, whether out of ignorance, because of business decisions, or some other reason. >you are implying/suggesting that one person should or does have >different pull with a vendor for an arbitrary reason, despite >explicitly stating otherwise in another section of the document. Some reporters *do* have different levels of credibility with certain Vendors, whether due to their reputation in the industry, or past interactions with the Vendor. But perhaps there should be another Vendor responsibility that captures your thinking. Section 3.3.1 (Vendor Responsibilities of the Notification Phase) could have an 8th bullet that tries to formalize this, but I'm not sure how to word it. If you're a Vendor and you get a report from a well-known security firm with fully functioning exploit code that gains root access, and the report comes in at the same time as an unknown individual's vague write-up about a root-level problem in an unspecified product, then the wording of this bullet should not prevent the Vendor from making the appropriate "triage" decisions. > 4) Within 10 days of initial notification, the Vendor's Security > Response Capability SHOULD provide a clear response to the Reporter > and any involved Coordinators. > >Perhaps suggest what this response should include. This wording suggests a >vendor can reply "we received your email" within 10 days and that is good. >To me that is not a 'clear response'. Correct me if I am wrong, but i >imagine you may mean a clear response is "we can reproduce the problem and >are working on a fix" or something more descript. Good point... how about: 4) Within 10 days of initial notification, the Vendor's Security Response Capability SHOULD provide a clear response to the Reporter and any involved Coordinators, indicating any progress that the Vendor has made with respect to (1) validating the reported issue, (2) determining a resolution, and (3) estimates for when the resolution will be available to customers. > 4) The Vendor SHOULD examine its product to ensure that it is free of > other problems that are similar to the reported vulnerability. > >This is a really good point, but one that may need some clarification >or vendors are likely to dismiss it. Weld reports a buffer overflow to >Microsoft. By the above paragraph, they are then suggested to examine >its product to ensure they are free of other problems of a similar >nature.. ie: buffer overflows. This turns into a full code audit. >While we all want that to happen, the odds of MS doing that in >response to a single vulnerability is unlikely. Perhaps some wording >to address that and let vendors know that it is a big task etc. The odds of *any* vendor with a large installation base doing a full code audit from a single report is unlikely, or at the very least, such an activity would take a much longer time than it would to fix a single issue. Perhaps there should be some flexibility for how Vendors decide to tackle the larger problem... but a non-responsible reporter, or a responsible reporter who believes that issues should be published within X days "no matter what," could make it difficult to formalize this flexibility. >More importantly, what if they do find more vulns, then what? I think >this is a great place to push vendors to report those bugs (after they >are fixed), or at least move away from the silent patching that goes >on. Hrmmm, I used to have something like this. I must have accidentally deleted it :-( Such an item would fit in the Release phases. > 5) The Vendor MUST consult with the Reporter and involved > Coordinators when more information or analysis is needed. > > 6) The Vendor SHOULD provide status updates to the Reporter and any > involved Coordinators every 7 days. The Vendor MAY negotiate with > the parties for less frequent updates. > > 7) The Vendor MUST notify the Reporter and any involved Coordinators > when the Vendor is able to reproduce the vulnerability. > >Each step above you explicitly state that the vendor should >mail the Reporter AND the Coordinator. Why? The Coordinator's role is >to help faciliate communication between a Reporter and Vendor that are >having difficulty finding a way to communicate. The Coordinator may help in resolving disputes if they arise, in which case their awareness would be useful. But these bullets do have an implicit assumption that the coordinator must stay involved throughout the process, which does not necessarily need to be the case, as you point out. > 10) If the Vendor is aware of other vendors that share the same > codebase as the affected product, then the Vendor MUST either (1) > notify those vendors, or (2) notify a Coordinator that other Vendors > may be affected by the reported vulnerability. > >This is not necessarily productive or ethical I don't think. If I >report a buffer overflow in an RPC daemon to Sun, and they know right >off that is very likely the same codebase as HP, AIX, Irix, Linux, >etc, it should be immediately reported to other vendors. I wasn't sure I understood this until I saw this... >The draft currently reads that after 30 days of sitting on >vulnerability information, they must share it with other vendors if it >affects them. That isn't very cooperative and doesn't help patch the >vuln quickly. In fact, vendors can use this as an extension method! You're right. Maybe this could be reworded to say that *as soon as* the Vendor suspects that a report is genuine, they should try to notify other vendors. This responsibility applies to the Reporter and the Coordinator, too. > 6) If the Vendor is unresponsive or disagrees with the Reporter's > findings, then the Reporter SHOULD involve a Coordinator. > >What if the Reporter has no Coordinator, and does not know who to consult >to find one? Hopefully the "responsible reporter" knows how to find a coordinator. I don't think we can document this in an RFC, since the set of coordinators or "procedures" for finding coordinators may change over time. The current procedures are basically "insider information" in that someone needs to observe the vulnerability research field for a while before figuring out who plays the coordinator role, but some reporters aren't in the information securiy industry at all. Your question does indicate a gap in this bullet. Perhaps we could use this wording: 6) If the Vendor is unresponsive or disagrees with the Reporter's findings, then the Reporter SHOULD attempt to involve a Coordinator. (I added "attempt to"). There is also a responsibility for the Security Community to raise reporter awareness about who the "coordinators" are, as well as other information about disclosure that is too dynamic or uncertain to capture in a best practices document, such as where and how to announce the vulnerability. I don't think that the vulnerability research community has been able to do this as a whole. Thanks for your extensive comments. Regards, - Steve From jericho@attrition.org Tue Feb 19 18:59:24 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA06448 for ; Tue, 19 Feb 2002 18:59:24 -0500 (EST) Received: from forced.attrition.org ([63.105.33.158]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA15861 for ; Tue, 19 Feb 2002 18:59:23 -0500 (EST) Received: from localhost (jericho@localhost) by forced.attrition.org (8.9.3/3.8.9) with SMTP id TAA07931; Tue, 19 Feb 2002 19:02:36 -0500 Date: Tue, 19 Feb 2002 19:02:36 -0500 (EST) From: security curmudgeon To: "Steven M. Christey" cc: saag@mit.edu In-Reply-To: <200202192319.SAA20802@linus.mitre.org> Message-ID: X-NoSpam: You do not have consent to spam me. X-Attrition: Attrition is only good when forced. http://www.attrition.org X-Copyright: This e-mail copyright 2002 by jericho@attrition.org where applicable X-Encryption: rot26 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] Re: Responsible Disclosure finally an Internet-Draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > >> 4) If the Vendor can control the e-mail addresses that it uses (e.g., > >> it has its own domain name), then the Vendor SHOULD define and > >> publish the "secalert" alias for use in vulnerability notification. > > >I disagree here. Two points why really. First, if vendors already have > >a 'security' alias, then they probably have someone watching it > >already. Vendors don't want to staff more people for this, that costs > >money. > > The thinking is to have a single alias that all vendors use, so that > vulnerability reporters don't have to wade through complicated web > sites or support forms. Correct. The need for a single alias on all vendor sites is definitely there, that I do not dispute at all. > >Suggesting and hinting that they use existing staff watching that > >alias is more friendly to their bottom line. Their staff can easily > >tell if it is a physical security or software security problem, and > >forward/respond to it accordingly. > > That's an interesting point. However, this still could require a > process change on the part of vendors, i.e. training their physical > security people to recognize security reports. (On the other hand, so > might a secalert alias, especially for Vendors who haven't established a > Security Response Capability yet). Correct. A guard who handles physical security should be able to quickly identify such mail. First, it comes from "that net thing" instead of someone from the company they guard. Second, it deals with all stuff not doors, turnstyles, walls, gates, etc. If their security can't pick out the difference between the two.. =) > >Actually a third thing comes to mind.. don't a few vendors use > >"secalert" already for distribution of their advisories? > > I did a web search when trying to think of a "neutral" but > security-related aliases. The closest alias I could find for secalert > is Oracle's "secalert_us" alias. A fresh search of Google shows that > Cray may already use this address; other matches on "secalert" are > directory or URL names. Ok. I had some idea that one of the big OS vendors used secalert already for distribution. > >If lowly jericho w/ attrition can't reach a vendor, and I know that > >one of the three names I just listed has a source there, that would > >fit the description above. > > The thinking is that besides a better contact list, Coordinators may > have more "name recognition" or apparent credibility than "lowly" > Jericho from attrition.org ;-) Even Rain Forest Puppy, one of the most > prominent vulnerability researchers, is not known to most vendors, and > he sometimes has issues with getting vendors to take his vulnerability > reports seriously, possibly as a result of his nym. The problem is > worse when Jane Doe or Joe Schmoe try to report an issue. Right. Instead of working so hard to create guidelines for the freaks (read: people with handles or odd names) to use to reach a vendor, simply demand that vendors not discriminate against those who wish to remain anonymous, or use a handle. It is *very* well proven that they can be qualified to do vuln research. Don't get me wrong, I'm not suggesting remove all the 'coordinator' parts, but perhaps just put emphasis on vendors being more open to reports regardless of name. > >I think you should add a caveat here or in the definition of a > >'coordinator' that explicity states they can not profit or benefit > >from my using them to practice responsible disclosure. It is easy for > >someone in a position like that to abuse the information and release > >it to their friends or some other group of people, even make money off > >it, all without my knowledge. In short, they would be abusing the > >system and abusing their status. > > Great point, but how does one define "benefit?" Coordinators may obtain > credibility for this work, which they might then highlight for marketing > or other purposes. True, 'benefit' can be vague. Perhaps someone on the list can come up with good wording to address the concern here. How do you explicitly state that a coordinator can not *profit*/benefit from their role? > >idea that vendors can/should see one vulnerability reporter as less > >credible than another. ANYONE following these steps, be it "Joe > >Consultant" or "Lord Viper Scorpion" should be given equal respect and > >credibility until they do something that betrays that credibility. > > ["Lord Viper Scorpion?" Is that a Jon Stewart/Daily Show reference?] I dont know the original use of the name, it has just caught on as a joke hacker name =) > A larger problem is that without peer review or "certification" for > reporters, it's difficult for a vendor to tell about someone's > credibility at face value. (Hopefully the Sardonix source-auditing True. But a reasonably well formed e-mail that explains a bug/vuln should stand as just that. > project will be fruitful in exploring this question.) This becomes a > problem for vendors who receive a number of vulnerability reports, many > of which may be rediscoveries of old issues, poorly worded, or lacking > important details for replication. Reporter credibility may help > vendors to conduct "triage" on vulnerability reports... as well as > better information in the initial vulnerability reports (but that's a > separate document). Vendor's should certainly begin to discriminate based on individuals. If someone is wasting their time, resending the same old bug that is proven wrong or already patched should not get recognized as a legit source. But for the first contact, the vendors need to be open to the idea that despite their name, and despite their grasp of the english language, they may be on top of things. > Some reporters *do* have different levels of credibility with certain > Vendors, whether due to their reputation in the industry, or past > interactions with the Vendor. Correct, as we both agree above. I'm aiming at covering the new reporter. > But perhaps there should be another Vendor responsibility that captures > your thinking. Section 3.3.1 (Vendor Responsibilities of the > Notification Phase) could have an 8th bullet that tries to formalize > this, but I'm not sure how to word it. If you're a Vendor and you get a > report from a well-known security firm with fully functioning exploit > code that gains root access, and the report comes in at the same time as > an unknown individual's vague write-up about a root-level problem in an > unspecified product, then the wording of this bullet should not prevent > the Vendor from making the appropriate "triage" decisions. This is probably good, but I am referring more to a single person reporting a vulnerability. > >Perhaps suggest what this response should include. This wording suggests a > >vendor can reply "we received your email" within 10 days and that is good. > >To me that is not a 'clear response'. Correct me if I am wrong, but i > >imagine you may mean a clear response is "we can reproduce the problem and > >are working on a fix" or something more descript. > > Good point... how about: > > 4) Within 10 days of initial notification, the Vendor's Security > Response Capability SHOULD provide a clear response to the Reporter > and any involved Coordinators, indicating any progress that the > Vendor has made with respect to (1) validating the reported issue, > (2) determining a resolution, and (3) estimates for when the > resolution will be available to customers. This sounds much better and more clear. > >The draft currently reads that after 30 days of sitting on > >vulnerability information, they must share it with other vendors if it > >affects them. That isn't very cooperative and doesn't help patch the > >vuln quickly. In fact, vendors can use this as an extension method! > > You're right. Maybe this could be reworded to say that *as soon as* the > Vendor suspects that a report is genuine, they should try to notify > other vendors. This responsibility applies to the Reporter and the > Coordinator, too. Yes. This is a tough one to deal with on all sides though, since it is difficult to know the code bases and their origin. > reporters aren't in the information securiy industry at all. > > Your question does indicate a gap in this bullet. Perhaps we could > use this wording: > > 6) If the Vendor is unresponsive or disagrees with the Reporter's > findings, then the Reporter SHOULD attempt to involve a > Coordinator. > > (I added "attempt to"). This is good. Is it out of line or inappropriate for an RFC to give details such as where to look or ask for one? ie: Can the RFC suggest they seek out a Coordinator on Bugtraq, Vulnwatch, etc? From coley@linus.mitre.org Tue Feb 19 19:30:40 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA06842 for ; Tue, 19 Feb 2002 19:30:40 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA24167 for ; Tue, 19 Feb 2002 19:30:40 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1K0Ud819753 for ; Tue, 19 Feb 2002 19:30:39 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1K0Uck23749 for ; Tue, 19 Feb 2002 19:30:38 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id TAA27548; Tue, 19 Feb 2002 19:30:38 -0500 (EST) Date: Tue, 19 Feb 2002 19:30:38 -0500 (EST) Message-Id: <200202200030.TAA27548@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Pete.Chown@skygate.co.uk said: >I read through the original document back in December and posted some >comments on the saag list. Did you get these okay, and if so what did >you think? I apologize. I did receive the comments, but due to the uncertain status of the original document and the possibility that this might be moved to a working group, I didn't answer you for fear of placing unnecessary focus on a document that might become obsolete, or at least inappropriate for the list. I thought I sent you an email saying this, but I guess I didn't :-( Sorry. But now's a good time to comment :-) On December 13, 2001, Pete.Chown@skygate.co.uk said: > I think the document is too long... The longer the document is, the > less people will read it. I agree that this is a concern. > I take the document to be saying that vendors get thirty days, plus > such extensions as they can negotiate with the reporters. Of course > there is a bit more detail than that, but it shouldn't take thirty > pages... The short answer is, I think that the process of responsible disclosure has many different variations, and there is no single approach that works for all situations. More specifically, there are a few problems that contribute to the length of the I-D: 1) We have a variety of types of players (reporters, vendors, coordinators, the security community, customers) that interact with each other in different ways. 2) The I-D tries to account for the cases when (1) one or more of the players aren't responsible, (2) when there is diasgreement across responsible parties, and (3) when all parties are responsible and things go smoothly. Obviously #3 is desired, but this rarely seems to happen :-) 3) There are some bullets that should be "painfully obvious" to security-aware readers... but they are *not* obvious, or at least not commonly adopted. For example, everybody *should* work together. But they don't always do so... and there will always be irresponsible reporters and vendors (at least relative to what this I-D is trying to say). 4) The topic of disclosure has been discussed extensively in the information security community, but the focus has been on reporter responsibilities. There has been little attention paid to what expectations there are for vendors, and there has been little attention paid to the role that coordinators may play. That is what distinguishes this I-D from the "de facto" vulnerability reporting standard, RFPolicy, which focuses on reporters - and is used primarily by reporters. 5) There are different opinions in how events should be timed - 5 days for this, 10 days for that. The unfortunate fact is that no single time frame applies to all situations. Some vendors have said that 30 days is not always long enough, and there are plausible reasons for how this can happen (such as "we support 5 different versions across several product lines on 10 different OSes and 8 hardware platforms."). 6) The rationales and notes attempt to capture some of the complexities of this issue, but unfortunately they contribute to the length of the I-D. 7) This I-D was written at a time of extensive debate where I think there were more "position papers" than in the past. These position papers, taken as a whole, present the complexity of the issue. (Some of the position papers are included in the references, but the list is by no means complete). There may be a way to reduce the size of this I-D without losing the flexibility and complexity, possibly through a major reorganization, but it escapes me at the moment :-/ >What status is it going for? Presumably Informational or BCP. In >this case I believe the requirements language -- the capitalised MUST, >SHOULD, and so on -- is out of place. The hope is to get to BCP status. I reviewed several process-oriented documents that used the requirements language, so there is precedent (BCP46 immediately comes to mind). The MUST and SHOULD usage seemed reasonable to make it clear that there are expectations for each player. It's also shorter than saying "it's recommended that..." or "it has been observed that, more often than not, ..." :-) >I think the document is made unnecessarily complicated by attempting >to be too precise or legalistic about what people are supposed to do.) IMHO, one of the biggest problems in the vulnerability disclosure debates is that people make arguments that are based on differing assumptions or motivations. Normally those arguments are one-sided, and "outlier" or controversial issues become prominent, to the point where people don't necessarily see that they agree on some basic principles. There is no single document for a focused discussion to take place. People make different simplifications, or they don't consider all the angles. The complexity of this process, along with the lack of a document that identifies *all* roles and responsibilities, contributes to the current state of affairs. >I feel the general security advice should be removed (for example 3.1 >paragraph 2). This advice is valuable but it is rather off the main >topic of this document. One difficulty that Chris Wysopal and I had in writing this document is that the role of the customer kept cropping up. The customers are ultimately responsible for using vulnerability information to secure their networks - in fixing the problems that are found, in reducing the impact of problems *before* they are found, and in pressuring vendors to make more secure products - but the customers are often ignored during the disclosure debates, or they are used as examples for why certain questionable (or at least sub-optimal) procedures should be followed. (An example argument: "we must release fully functioning exploit code because CTO's and sysadmins won't believe the problem is real otherwise.") That's why sections such as 3.7.4 (customer responsibilities in the release phase) are included. Customers play an important role in the disclosure process, whether they know it or not. - Steve From randy@psg.com Tue Feb 19 19:12:34 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA06604; Tue, 19 Feb 2002 19:12:34 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA26357; Tue, 19 Feb 2002 19:12:33 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16dKN6-000AxV-00; Tue, 19 Feb 2002 16:12:32 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: saag-request@mit.edu Cc: saag@mit.edu Subject: Re: [saag] Re: Responsible Disclosure finally an Internet-Draft References: <200202192319.SAA20802@linus.mitre.org> Message-Id: Date: Tue, 19 Feb 2002 16:12:32 -0800 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: unsubscribe --- i give up From crawdad@gungnir.fnal.gov Wed Feb 20 11:45:19 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA16763 for ; Wed, 20 Feb 2002 11:45:18 -0500 (EST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29567 for ; Wed, 20 Feb 2002 11:45:18 -0500 (EST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GRU00FUXBVI3B@smtp.fnal.gov> for saag@mit.edu; Wed, 20 Feb 2002 10:45:18 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g1KGjGZ26230; Wed, 20 Feb 2002 10:45:16 -0600 (CST) Date: Wed, 20 Feb 2002 10:45:16 -0600 From: Matt Crawford Subject: Re: [saag] Re: Responsible Disclosure finally an Internet-Draft In-reply-to: "19 Feb 2002 16:12:32 PST." To: Randy Bush Cc: saag@mit.edu Message-id: <200202201645.g1KGjGZ26230@gungnir.fnal.gov> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Randy Bush sez: > unsubscribe > --- > > i give up Gee, Randy, I managed to resist the urge to send a "last word" barb to *your* lists when I unsubscribed. Maybe with more practice ... From shalunov@internet2.edu Wed Feb 20 22:32:40 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA23765 for ; Wed, 20 Feb 2002 22:31:22 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA04315 for ; Wed, 20 Feb 2002 22:30:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id A8BB65EE0A; Wed, 20 Feb 2002 22:30:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 8302E5EE07; Wed, 20 Feb 2002 22:30:35 -0500 (EST) To: "Steven M. Christey" , Chris Wysopal Cc: saag@mit.edu From: stanislav shalunov Date: 20 Feb 2002 22:31:11 -0500 Message-ID: <87k7t7o6io.fsf@cain.internet2.edu> Lines: 122 X-Mailer: Gnus v5.7/Emacs 20.4 Subject: [saag] draft-christey-wysopal-vuln-disclosure-00.txt Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: [It appears from previous exchanges that it is understood that sending the comments on this draft to the saag list is appropriate. If it is not, let me know and I will not comment on the list any further.] While having a BCP that describes vulnerability reporting guidelines could be useful, the current version of the document could be improved if it were made much more concise and somewhat less formal. The key words from RFC2119 should probably be reserved for standards track documents. This draft is a BCP candidate that does not describe a computer communication protocol and therefore should probably not use them. The sheer length of the document is overwhelming. The amount of detail and motivation might be appreciated in an essay, but 27 pages to specify a few simple rules is simply too much. The rules themselves (mostly) make sense. The discussion that leads to their establishment should probably not be included in the final product. The URLs will rot. > 1.3 Motivations Everything in this section is fine, but does it help to know the authors' (or the IETF's) view of motivations of different parties to follow the suggested process? Maybe this discussion could be shortened and embedded in definition of roles. > 1.4 Goals of Responsible Disclosure This, again, seems too lengthy. > 1) The Vendor SHOULD ensure that programmers, designers, and testers > are knowledgeable about common flaws in the design and implementation > of products. What does it have to do with vulnerability reporting? > 2) Customers SHOULD configure their products and systems in ways that > eliminate latent flaws or reduce the impact of latent flaws, What does this generic (and sound) advice have to do with vulnerability reporting? > 3) The Security Community SHOULD track all known vulnerabilities to > identify new classes of vulnerabilities, How can you require anything of a large loosely-knit community of individuals? The requirements are to be for individual parties. This is the equivalent of saying that network hosts should avoid congestion collapse and use the network efficiently and fairly instead of specifying the congestion avoidance algorithm to be used by individual hosts. What is it doing in this document, anyway? > 1) The Reporter SHOULD make a reasonable effort to ensure that: - the > vulnerability is real - the process of getting the product into a > known exploitable state is repeatable This sounds like heisenbugs aren't real bugs and shouldn't be reported. > 2) The Vendor SHOULD establish a Security Response Capability (SRC) > that consists of one or more individuals or groups that are > responsible for responding to vulnerability reports, verifying > vulnerabilities, releasing bulletins, etc. Is this suggesting a business practice? So, a free software developer needs to establish a "Security Response Capability (SRC)"? Or should he just fix the bugs? And is it even the fucntion of this document to tell the developer to fix the bugs? > 3) The Vendor SHOULD ensure that its staff knows how to recognize a > reported security issue and direct it to the Security Response > Capability. This sounds like more business practice advice. Is IETF about recommending business practices or making Internet protocols? > 4) If the Vendor can control the e-mail addresses that it uses (e.g., > it has its own domain name), then the Vendor SHOULD define and > publish the "secalert" alias for use in vulnerability notification. Sounds like you want to amend section 3 of RFC2142. If that's the case, then it should not be in this document. > 5) If the Vendor operates a web site or other means of distributing > information regarding its product, then the Vendor SHOULD create and > publish a "security" page or folder that identifies how vulnerability > reports should be made. The Vendor SHOULD make this page easy to > find from other locations, such as a separate contact page or index. This looks like information representation design advice. > 6) The Vendor MUST provide a facility for individuals or > organizations who are not Customers to report vulnerabilities. MUST here must mean that the Internet will break if this isn't done. This shouldn't be the case at least for software that's not network-related. This is the point in the document where I gave up reading. Why don't you just say this (should fit on one page): Give the vendor a chance to work on a problem report before you publish bug details. In your communication to the vendor specify when you plan to release your information publicly. You should allow the vendor an appropriate amount of time to fix the bug (not less than two weeks unless the vulnerability is already being actively exploited). I, by the way, couldn't understand it from your document (I'm sure it's there somewhere) what amount of time you expect people to wait before they fire the bugtraq message off in the case of unresponsive vendors. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at 600 mph. From jlargent@imagelinks.com Thu Feb 21 08:16:48 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA29671 for ; Thu, 21 Feb 2002 08:16:47 -0500 (EST) Received: from dante.imagelinks.com (dante.imagelinks.com [208.24.120.33]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA21076 for ; Thu, 21 Feb 2002 08:16:47 -0500 (EST) Received: from imagelinks.com (mcfarland.imagelinks.com [208.24.120.38]) by dante.imagelinks.com (8.11.6/8.11.6) with ESMTP id g1LDGkb30120 for ; Thu, 21 Feb 2002 08:16:46 -0500 Message-ID: <3C74F33E.2090002@imagelinks.com> Date: Thu, 21 Feb 2002 08:16:46 -0500 From: Jeff Largent Organization: Imagelinks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] INTERNET-DRAFT MITRE Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: As the person responsible for the computer security I see several problems with the time frame for Vendor response. The way it is layed out allows a vendor to delay any fix for an almost indefinate period of time. 7 days just to acknowledge receipt to the reporter or if you use a auto reply another 10 days on top of that. So we are alread at 17 day and nothing is done. If one person has discovered the vulnerability a second person will find the same problem in this time frame. If this person is not a white hat we have a problem. The vendor should reply to the security community(Bugtraq?) within 14 days. This would allow the evaluation of systems by admins running the product. If a fix is not available the service/program can be shutdown/replaced until a fix is available, not forced down by having your system hacked. The Rationale for the time period of receipt is faulty. This is a security issue, not some it dosn't work problem. The standard work week goes out the door for situations like this. I know it will not be a factor if one of my systems are hacked on a friday night. It's the weekend I'll fix it monday, most likly if I wait till monday what will happen is I will be looking for a job. Jeff Largent From OgleR@thmulti.com Thu Feb 21 09:00:15 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA00192 for ; Thu, 21 Feb 2002 09:00:14 -0500 (EST) Received: from ns1.thmulti.com (ns1.thmulti.com [141.11.234.67]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA01924 for ; Thu, 21 Feb 2002 09:00:13 -0500 (EST) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id PAA14551; Thu, 21 Feb 2002 15:00:11 +0100 (MET) Received: from parexch9.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id PAA21735; Thu, 21 Feb 2002 15:00:11 +0100 (MET) Received: by outlook.paris.thmulti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 15:00:14 +0100 Message-ID: <05B4910E0216D411B14F00508B6A67A9029419C6@RENEXCH5.rennes.thmulti.com> From: "Ogle Ron (Rennes)" To: "'Jeff Largent'" , saag@mit.edu Subject: RE: [saag] INTERNET-DRAFT MITRE Date: Thu, 21 Feb 2002 15:00:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: One of the expected security incidents of this year is a zero day vulnerability exploited by a quick spreading virus. I'd hate to be on the receiving side of the lawsuits because the vulnerability was actually known but not communicated out. The time frame to at least acknowledge the problem should very short. This way I can at least prepare to be hit and put in the proper filters or sniffing profiles. The same analogy can be seen in the Anti-virus world. In the old days, I had days or weeks to install my virus patterns. Two years ago, I was getting virus patterns daily and still felt safe. Today, I can't get the virus pattern quickly enough. The Anti-virus companies are now sending out information on what to look for as soon as they get it and before they have a patch or pattern file. Why is this? The reason is that I can use this information to put in countermeasure such as using content filtering or firewall blocks to prevent the infection or the spread before I have the anti-dote. Of course, in the next hours I will give the virus pattern update or patch which I will then install on all machines. We already see that the virus writers are putting in newer and newer vulnerabilities into their code to exploit. What will we say to all of the businesses who lost $Ms or even $Bs to clean up a new vulnerability problem. When they could have had the tools to prevent much of the destruction? But the RFC said so? Will this RFC give cover for the players against the lawyers? We all have to live in reality. Reality is the time frame is shrinking between finding a vulnerability, exploiting the vulnerability, and implementing mass destruction using the vulnerability. The RFC has to support reality! Thanks Ron Ogle Rennes, France -----Original Message----- From: Jeff Largent [mailto:jlargent@imagelinks.com] Sent: Thursday, February 21, 2002 2:17 PM To: saag@mit.edu Subject: [saag] INTERNET-DRAFT MITRE .... The Rationale for the time period of receipt is faulty. This is a security issue, not some it dosn't work problem. The standard work week goes out the door for situations like this. I know it will not be a factor if one of my systems are hacked on a friday night. It's the weekend I'll fix it monday, most likly if I wait till monday what will happen is I will be looking for a job. Jeff Largent _______________________________________________ saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag From smb@research.att.com Thu Feb 21 09:17:59 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA00456 for ; Thu, 21 Feb 2002 09:17:58 -0500 (EST) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA07213 for ; Thu, 21 Feb 2002 09:17:58 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 3EC434CEA3; Thu, 21 Feb 2002 09:17:58 -0500 (EST) Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id JAA08825; Thu, 21 Feb 2002 09:14:09 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id E2A707B4B; Thu, 21 Feb 2002 09:17:55 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Jeff Largent Cc: saag@mit.edu Subject: Re: [saag] INTERNET-DRAFT MITRE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Feb 2002 09:17:55 -0500 Message-Id: <20020221141756.E2A707B4B@berkshire.research.att.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > >The Rationale for the time period of receipt is faulty. This is a security >issue, not some it dosn't work problem. Yes, but. The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back. Fred Brooks, "The Mythical Man Month", 1975. I'm not at all in favor of dawdling. But let's remember that the reason we're in this mess is too much bad code that wasn't properly designed or tested. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From coley@linus.mitre.org Thu Feb 21 15:05:28 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA15280 for ; Thu, 21 Feb 2002 15:05:28 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA29187 for ; Thu, 21 Feb 2002 15:05:27 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1LK5R814964 for ; Thu, 21 Feb 2002 15:05:27 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1LK5Pk08369 for ; Thu, 21 Feb 2002 15:05:25 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id PAA01268; Thu, 21 Feb 2002 15:05:25 -0500 (EST) Date: Thu, 21 Feb 2002 15:05:25 -0500 (EST) Message-Id: <200202212005.PAA01268@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: [saag] Re: draft-christey-wysopal-vuln-disclosure-00.txt Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: The draft has generated about 100 comments so far on slashdot at http://slashdot.org/comments.pl?sid=28332 . I've also received some emails sent directly to me instead of SAAG. I will (somehow) summarize and excerpt those external comments in a single message at a later day. I will be replying to SAAG posts shortly. - Steve From jericho@attrition.org Thu Feb 21 16:49:49 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA17776 for ; Thu, 21 Feb 2002 16:49:49 -0500 (EST) Received: from forced.attrition.org ([63.105.33.158]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA15186 for ; Thu, 21 Feb 2002 16:49:48 -0500 (EST) Received: from localhost (jericho@localhost) by forced.attrition.org (8.9.3/3.8.9) with SMTP id QAA26965; Thu, 21 Feb 2002 16:53:11 -0500 Date: Thu, 21 Feb 2002 16:53:11 -0500 (EST) From: security curmudgeon To: "Steven M. Christey" cc: saag@mit.edu In-Reply-To: <200202212049.PAA08555@linus.mitre.org> Message-ID: X-NoSpam: You do not have consent to spam me. X-Attrition: Attrition is only good when forced. http://www.attrition.org X-Copyright: This e-mail copyright 2002 by jericho@attrition.org where applicable X-Encryption: rot26 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] Re: Responsible Disclosure finally an Internet-Draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > >> = me > > = security curmudgeon > = Steven M. Christey > >Correct. A guard who handles physical security should be able to > >quickly identify such mail. First, it comes from "that net thing" > >instead of someone from the company they guard. Second, it deals with > >all stuff not doors, turnstyles, walls, gates, etc. If their security > >can't pick out the difference between the two.. =) > > True. > > I'll try to do more research on the intentions for the "security" > alias; RFC2142 says it's for "Security bulletins or queries," which > seems to leave some room for interpretation. (Is it a *source* address > for vendors who send out bulletins? An alias for customers to use when > subscribing to bulletin mailing lists? For reporting specific computer > security incidents such as scanning activity?) Yeah, 2142 is a bit vague there. I don't know the procedure/etiquette on building on or clarifying other aliases, but I think it would be appropriate if you guys would clear this up for them when you define the accepted alias for reporting bugs. > >> A larger problem is that without peer review or "certification" for > >> reporters, it's difficult for a vendor to tell about someone's > >> credibility at face value. > > > >True. But a reasonably well formed e-mail that explains a bug/vuln > >should stand as just that. > > Our "sister document" on advisory contents will cover initial > notification as well as public release. Reporters who follow the > recommendations (or use a template) will gain credibility while > simultaneously helping the vendor to validate the issue. Has a draft of this been released? I haven't seen it yet (sounds liek it is in the works). Either way, that is another document that clearly needs to be written. > >This is good. Is it out of line or inappropriate for an RFC to give > >details such as where to look or ask for one? ie: Can the RFC suggest > >they seek out a Coordinator on Bugtraq, Vulnwatch, etc? > > My take on things, based on other RFC's I've read and probably some IETF > or RFC Editor guidance somewhere, is that you should try to avoid > specifics that could change over time. This is why various coordinators > were not explicitly named. But maybe the coordinator definition is too > vague. I don't think of Bugtraq or Vulnwatch as coordinators per se; > they are "publications" (albeit mailing lists). It's the moderators of > such lists who may act as coordinators (e.g., Russ Cooper of NTBUGTRAQ, > SecurityFocus VulnHelp service) as well as organizations like CERT/CC. Right. I mention those because despite being a publication, the moderators typically do have contacts with the vendors and would serve well as Coordinators. Brian From aleph1@securityfocus.com Thu Feb 21 03:30:31 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id DAA26982 for ; Thu, 21 Feb 2002 03:30:31 -0500 (EST) From: aleph1@securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id DAA16984 for ; Thu, 21 Feb 2002 03:30:31 -0500 (EST) Received: (qmail 30135 invoked by uid 101); 21 Feb 2002 08:29:30 -0000 Date: Thu, 21 Feb 2002 01:29:30 -0700 To: saag@mit.edu Subject: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Message-ID: <20020221082930.GA24687@securityfocus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This is a response to the earlier draft. Since no significant changes were made they still apply. > 1.4 Goals of Responsible Disclosure > > The goals of responsible disclosure include: > > 1) Ensure that vulnerabilities can be identified and eliminated > effectively and efficiently for all parties. As you've mentioned before different parties can have conflicting goals. You cannot ensure that vulnerabilities can be identified and eliminated effectively and efficiently for all parties. It would be better if you actually spelled out what balance have you struck. > 2) Minimize the risk to customers from vulnerabilities that could > cause damage to their systems. Ditto. For example, by keeping vulnerability information secret while you wait for a vendor fix you maintain at risk those that could do something to minimize their risk without an official fix. You have opted to minimize the risk of the large population of non-technical users at the short-term expense of technical users. I am not arguing whether this is right or wrong, just that you need to point out the biases in the selected process. This document makes an assumption and it needs to be spelled out. > 5) If the Vendor operates a web site or other means of distributing > information regarding its product, then the Vendor SHOULD create and > publish a "security" page or folder that identifies how vulnerability > reports should be made. The Vendor SHOULD make this page easy to > find from other locations, such as a separate contact page or index. What about suggestion a canonical URL as you do for email? e.g. /security > 3) If the Vendor's receipt message is automatically generated, then > it SHOULD include a time period or date by which an individual (or > the Security Response Capability) will provide follow-up on the > reported vulnerability. The time period SHOULD NOT exceed 10 days. 10 days from when? notification or receipt? The next point makes it seem notification but its better to be clear. > 4) Within 10 days of initial notification, the Vendor's Security > Response Capability SHOULD provide a clear response to the Reporter > and any involved Coordinators. > 4) If a Reporter has properly followed the process, then the Vendor > MUST provide credit to that reporter. What defines "properly"? The are a lot of shoulds in this document. Only "musts" need to be meet for the process to have been done "properly"? E.g. the vendor MAY ask for 30 day blackout on detailed information. Many people will not agree. Does that mean Microsoft will give those users credit in the advisories? I doubt it. It would be against Microsoft policy. Then, does that mean Microsoft will not have followed this process "properly"? > 5) If a Coordinator has properly followed the process, then the > Vendor SHOULD provide credit to the Coordinator. Ditto. > 4) If a Vendor requests a Grace Period, then the Reporter SHOULD > follow the Grace Period before releasing details of the > vulnerability. Here you are injecting your bias into the process. s/SHOULD/MAY/ > 2) If the Vendor requests a Grace Period, the Coordinator SHOULD > follow the Grace Period and encourage the Reporter to follow the > Grace Period. Ditto. s/SHOULD/MAY/ My main objection to the draft is that, while Steve agrees that no one set of time tables can apply to all situations, the process defines gives vendors a minimum of 30 days to clean up their act. That may be proper is most cases but not all. I am afraid that if this document becomes an RFC that it will be used by vendors to ostracize any reporters that do not agree to at least the 30 day window. We all know how companies quote RFC numbers and claim them to be standards even when they are nothing more than informational. The document also make no provisions for situations that may require the reporter to disclose early such as when the vulnerability is being exploited in the wild, when waiting for a vendor fix would be more damaging than warning users early (e.g. to stop them from using the dangerous feature), or when this whole process is almost never follwed (e.g. academic publishing of flaws in a design such as IPsec or 802.11). -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum From eddiealz@eudoramail.com Thu Feb 21 04:08:21 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA27357 for ; Thu, 21 Feb 2002 04:08:17 -0500 (EST) Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id EAA05950 for ; Thu, 21 Feb 2002 04:08:16 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Thu Feb 21 01:08:05 2002 To: saag@mit.edu Date: Thu, 21 Feb 2002 01:08:05 -0800 From: "Edward Alz" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: eddiealz@eudoramail.com X-Mailer: MailCity Service X-Sender-Ip: 24.128.190.210 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Subject: [saag] Re: Responsible Disclosure finally an Internet-Draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I don't see the value in the ietf deciding on requirements for the behavior of vendors -- in contexts far removed from Internet operational needs. That a Customer obtains a supported Product from a Vendor does not, to me, imply that the Vendor MUST absorb whatever costs are associated with assisting any Reporter in addressing a vulnerability. It's useful if the vendor sets appropriate expectations about whether a network application is suited to high-risk network environments. It's useful if the vendor comments on how security was considered in the design. It's even more useful if the vendor outlines what approach they used to avoid common implementation flaws. Except in clear cases where essentially *any* use of the program will see untrusted input from the outside world (e.g. mail agents), there can be huge value in having software available at all, even if the Vendor is unconcerned with security. Take an open-source application that provides, say, a "better" (in some way) database. If it says in big letters "Here's a database that you can run standalone, and I answer support e-mails. But it'll also read data over the network. The code that reads it might be wrong. I didn't audit it. No one else audited it. If you need to use this on a network, SPEND YOUR OWN MONEY and get the network code audited and fixed." this should be 100% ok. With the big letters, no one should accuse the author of violating Best Current Practice just because he likes to write the database pieces and couldn't care less about his strcpy(little_buf, big_network_buf). Same principle even for Microsoft. As long as users really were told about the risk expectations for PWS (e.g. http://archives.neohapsis.com/archives/bugtraq/2001-03/0242.html) there ought to be no need for Microsoft to follow any of the MUST options in 3.5.1 (1). To summarize: "end user says the magic word 'vulnerability'" should not always imply "vendor must spend time/money to satisfy user". Similarly, "vendor says the magic phrase 'I don't understand the vulnerability'" should not imply "reporter should become an unpaid member of vendor's QA team". Yeah, often the reporter uses the product and really wants the vulnerability fixed, and then helping the vendor is to everyone's advantage. If not, then 3.5.2 (1) is nice and all, but for Best Current Practice to boil down to "work for free" seems inappropriate. I'd be happier with "if Vendor does not gain clue within amount of time Reporter can afford, then Reporter should disclose and ask General Public (or Coordinator) to help give clue to Vendor". --eddie Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From tim@fungible.com Thu Feb 21 09:28:20 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA00575 for ; Thu, 21 Feb 2002 09:28:20 -0500 (EST) Received: from lobus.fungible.com (adsl-64-161-114-6.dsl.snfc21.pacbell.net [64.161.114.6]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA27737 for ; Thu, 21 Feb 2002 09:28:19 -0500 (EST) Received: by lobus.fungible.com (Postfix, from userid 1000) id 0DDB7AEFC9; Thu, 21 Feb 2002 06:26:44 -0800 (PST) Message-Id: <1191-Thu21Feb2002062643-0800-tim@fungible.com> X-Mailer: emacs 21.1.1 (via feedmail 8 I) Date: Thu, 21 Feb 2002 06:05:57 -0700 From-Tims-Fingers: true To: saag@mit.edu Cc: coley@linux.mitre.org From: tim@fungible.com (Tim Freeman) Subject: [saag] Vulnerability Disclosure: When does grace period start; comments Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: The vulernerability disclosure document at http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt has two minor flaws I can see now: 1. It says: The Vendor MAY ask the Reporter and Coordinator to allow a "Grace Period" up to 30 days, during which the Reporter and Coordinator do not release details of the vulnerability that could make it easier for hackers to create exploit programs. There is no indication of when the grace period starts. It might start at the time of initial notification, or it might start at the time the vendor has resolved the vulnerability. 2. The document does not include any email addresses that can be used for discussing its contents or contacting the authors. -- Tim Freeman tim@fungible.com; formerly tim@infoscreen.com P. S. You've been slashdotted; that is, your document is pointed to by http://www.slashdot.org, and it will therefore get a lot of attention. I hope you can deal with the noise. From aleph1@securityfocus.com Thu Feb 21 16:13:40 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA17028 for ; Thu, 21 Feb 2002 16:13:40 -0500 (EST) From: aleph1@securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id QAA04197 for ; Thu, 21 Feb 2002 16:13:40 -0500 (EST) Received: (qmail 787 invoked by uid 101); 21 Feb 2002 21:12:34 -0000 Date: Thu, 21 Feb 2002 14:12:34 -0700 To: saag@mit.edu Subject: (forw) [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Message-ID: <20020221211234.GA15269@securityfocus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: My apologies if this is a duplicate. I sent it earlier today and have yet to see it in the archives. ----- Forwarded message from aleph1@securityfocus.com ----- From: aleph1@securityfocus.com To: saag@mit.edu Subject: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Date: Thu, 21 Feb 2002 01:29:30 -0700 Message-ID: <20020221082930.GA24687@securityfocus.com> This is a response to the earlier draft. Since no significant changes were made they still apply. > 1.4 Goals of Responsible Disclosure > > The goals of responsible disclosure include: > > 1) Ensure that vulnerabilities can be identified and eliminated > effectively and efficiently for all parties. As you've mentioned before different parties can have conflicting goals. You cannot ensure that vulnerabilities can be identified and eliminated effectively and efficiently for all parties. It would be better if you actually spelled out what balance have you struck. > 2) Minimize the risk to customers from vulnerabilities that could > cause damage to their systems. Ditto. For example, by keeping vulnerability information secret while you wait for a vendor fix you maintain at risk those that could do something to minimize their risk without an official fix. You have opted to minimize the risk of the large population of non-technical users at the short-term expense of technical users. I am not arguing whether this is right or wrong, just that you need to point out the biases in the selected process. This document makes an assumption and it needs to be spelled out. > 5) If the Vendor operates a web site or other means of distributing > information regarding its product, then the Vendor SHOULD create and > publish a "security" page or folder that identifies how vulnerability > reports should be made. The Vendor SHOULD make this page easy to > find from other locations, such as a separate contact page or index. What about suggestion a canonical URL as you do for email? e.g. /security > 3) If the Vendor's receipt message is automatically generated, then > it SHOULD include a time period or date by which an individual (or > the Security Response Capability) will provide follow-up on the > reported vulnerability. The time period SHOULD NOT exceed 10 days. 10 days from when? notification or receipt? The next point makes it seem notification but its better to be clear. > 4) Within 10 days of initial notification, the Vendor's Security > Response Capability SHOULD provide a clear response to the Reporter > and any involved Coordinators. > 4) If a Reporter has properly followed the process, then the Vendor > MUST provide credit to that reporter. What defines "properly"? The are a lot of shoulds in this document. Only "musts" need to be meet for the process to have been done "properly"? E.g. the vendor MAY ask for 30 day blackout on detailed information. Many people will not agree. Does that mean Microsoft will give those users credit in the advisories? I doubt it. It would be against Microsoft policy. Then, does that mean Microsoft will not have followed this process "properly"? > 5) If a Coordinator has properly followed the process, then the > Vendor SHOULD provide credit to the Coordinator. Ditto. > 4) If a Vendor requests a Grace Period, then the Reporter SHOULD > follow the Grace Period before releasing details of the > vulnerability. Here you are injecting your bias into the process. s/SHOULD/MAY/ > 2) If the Vendor requests a Grace Period, the Coordinator SHOULD > follow the Grace Period and encourage the Reporter to follow the > Grace Period. Ditto. s/SHOULD/MAY/ My main objection to the draft is that, while Steve agrees that no one set of time tables can apply to all situations, the process defines gives vendors a minimum of 30 days to clean up their act. That may be proper is most cases but not all. I am afraid that if this document becomes an RFC that it will be used by vendors to ostracize any reporters that do not agree to at least the 30 day window. We all know how companies quote RFC numbers and claim them to be standards even when they are nothing more than informational. The document also make no provisions for situations that may require the reporter to disclose early such as when the vulnerability is being exploited in the wild, when waiting for a vendor fix would be more damaging than warning users early (e.g. to stop them from using the dangerous feature), or when this whole process is almost never follwed (e.g. academic publishing of flaws in a design such as IPsec or 802.11). -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum ----- End forwarded message ----- -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum From svh@cert.org Thu Feb 21 16:56:32 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA17955 for ; Thu, 21 Feb 2002 16:56:32 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17072 for ; Thu, 21 Feb 2002 16:56:32 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.65) with ESMTP id QAA24350; Thu, 21 Feb 2002 16:56:29 -0500 (EST) Received: from firstbase.blue.cert.org (firstbase.blue.cert.org [10.10.10.45]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id QAA05325; Thu, 21 Feb 2002 16:56:29 -0500 (EST) Date: Thu, 21 Feb 2002 16:56:27 -0500 Mime-Version: 1.0 (Apple Message framework v481) Cc: "Steven M. Bellovin" , cwysopal@atstake.com, coley@mitre.org Message-Id: In-Reply-To: <20020221141756.E2A707B4B@berkshire.research.att.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [saag] INTERNET-DRAFT MITRE From: "Shawn V. Hernan" Content-Transfer-Encoding: 7bit To: saag@mit.edu X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Thursday, February 21, 2002, at 09:17 AM, Steven M. Bellovin wrote: > I'm not at all in favor of dawdling. But let's remember that the > reason we're in this mess is too much bad code that wasn't properly > designed or tested. > I could not agree more wholeheartedly with Steve, and indeed I think much of the energy spent on debating disclosure issues would be better spent on finding ways to avoid or detect security problems more efficiently. Nonetheless, security problems exist, and they must be disclosed. The issue at hand is how can security problems be disclosed in such a way as to minimize compromises and the risk of compromises. I have personally given a great deal of thought to this problem over the years, and am interested in reaching a consensus as to what is reasonable. I applaud the efforts of Mitre and @stake to tackle such a thorny issue, though I do have some concerns about the existing draft. To begin with the section on motivation describes vendor motivation in terms of their behaviors or attributes. For example, it says, "Some vendors may not have the technical skills to understand the nature of the vulnerability and the risk that it poses. " While this is true, it is not a motivation. Likewise, being unresponsive is not a motivation either. Vendors are motivated in many cases by cost, as is appropriate for a for-profit organization, enlightened self interest, and good citizenship. For example, a perfectly reasonable (though IMHO shortsighted) motivation for a vendor would be for that vendor to improve the *relative* security posture of their products vs. competitors. For example, a vendor may choose to audit a commonly used piece of code, fix any vulnerabilities, and never disclose their existence to their competitors. Reporters, customers , and coordinators may be motivated by different things too. For example, a coordinator may be motivated by the desire to see a vulnerability properly scoped before public notification. Too often system administrators are forced to evaluate "the same" vulnerability multiple times because vendor A addressed it months or years before vendor B ever even heard of it. But what's missing from the motivation section is the implicit assumption that disclosure in any form is a good thing at all. It is not intrinsicly obvious that disclosing a vulnerability AT ALL is a Good Thing. I am certain that vendors fix vulnerabilities all the time that never get disclosed to anyone. Should those vulnerabilities be disclosed too? Personally, I believe they should be disclosed because I believe that individuals and corporations have a right to know what risks they are facing. But I am unaware of any empirical data to support the argument for any particular vulnerability. Having said that, if there exists a non-zero chance that a malicious person will discover any *individual* non-disclosed vulnerability, then integrated over time there is a 100% chance that a malicious individual or group will find some undisclosed vulnerability. And the consequences of that discovery could be quite severe. Therefore (and for many other reasons) , I believe it is in our best collective interests to responsibly disclose vulnerabilities as the best way to have faith in the overall security of the network. I believe the existing draft fails to provide motivation for disclosing vulnerabilities at all, and instead speaks to a process for doing it. In other words, not everyone has agreed that disclosure is a good thing, and a document that speaks about the best way to do it utterly fails to reach that audience. So what? People who do not want to do the right thing won't follow any RFC. Irrational people are going to act in self-destructive (or random) ways. And *that* is a community we desperately need to reach. I'd rather avoid issues of arguing over RFC compliance, and instead spend that time convincing everyone that if the want to do the right thing, then certain behaviors are empirically found to be beneficial, and providing people with sets of issues to consider when formulating their own rational plan for disclosing a vulnerability. All of which leads me to the conclusion that before this document can be useful, we need to provide empirical data in support of the implicit assumption that disclosure is beneficial. I would prefer a series of well-thought-out essays and articles, backed by empirical data that will and I would be willing to cooperate on such a venture. I'll even concede that perhaps such a document could be presented as an RFC. Having said all that, I offer some specific comments below with the caveat that I would prefer a different approach to this issue. > 2) If the Reporter is unable to notify the Vendor, then the Reporter > SHOULD ask a Coordinator to notify the Vendor. The Reporter SHOULD > provide the Coordinator with a list of contacts or mechanisms that were > used to attempt to notify the Vendor. There are additional reasons people may wish to contact a coordinator, not the least of which is proper scoping, encrypted communications (ever try to encrypt mail to 100 different vendors before?) third-party objectivity, etc. I think it is insufficient to involve coordinators only if the vendor is somehow unresponsive. > 2) The Vendor MUST provide the Reporter and involved Coordinators with > a Receipt within 7 days. I think putting time frames on communications processes will simply lead to arguments over whether or not someone was "conformant" to the RFC, and will provide excuses for people to act in random ways because the "other guy" violated the RFC. "After 7 days, I can do whatever I want" does not seem to be consistent with the spirit of this work. Likewise, why should "small" vendors somehow be exempt? There seems to be an implicit assumption that there is less pressure per person if the vendor is large. > 1) If the vulnerability is found in a supported product, the Vendor > MUST either (1) reproduce the vulnerability, What does it mean to "reproduce" a vulnerability? There seems to be an implicit assumption that an exploit for the vulnerability exists. I am very concerned that as a community, we are promulgating the idea that the best way to recognize bad software is to have a tool that exploits it. I would much rather see standards and guidelines that help developers understand *why* certain constructs are bad, rather than having to demonstrate time and time again that strcpy is dangerous. To make an analogy, a civil engineer does not need to "reproduce" a crack in a bridge to know what kinds of cracks are dangerous, and which aren't. The time for breaking things and seeing why they're broken is when you're in college studying or researching good design. An engineer ought to know that some things are just bad. > The Vendor SHOULD NOT assume that the risk or impact of the > vulnerability is limited to what has been identified by the Reporter or > involved Coordinator. Additionally, no one should assume that the vulnerability is limited to products from a specific vendor. > The Vendor SHOULD examine its product to ensure that it is free of > other problems that are similar to the reported vulnerability. Well, this is certainly true, but as a practical matter, does it add anything to the value of the document? Its certainly not about disclosure. Why not include a statement that says "The Vendor MUST NOT introduce buffer overflows into their products." :-) > 5) The Vendor MUST consult with the Reporter and involved > Coordinators when more information or analysis is needed. > > 6) The Vendor SHOULD provide status updates to the Reporter and any > involved Coordinators every 7 days. The Vendor MAY negotiate with > the parties for less frequent updates. What if the reporter (or even the coordinator) doesn't want to be involved beyond the initial report. There is an implicit assumption throughout the document that the reporters are interested in the results. In many cases, the reporter found a problem and are reporting it just to be good citizens. They may not be affected by it at all, and don't want to be further bothered. > 8) The Vendor SHOULD attempt to resolve the vulnerability within 30 > days of initial notification. > > 9) If the Vendor cannot resolve the vulnerability within 30 days, > then the Vendor MUST provide the Reporter and involved Coordinators > with specific reasons why the vulnerability cannot be resolved. I think 30 days is too short to expect resolution in most cases. 45 days is pretty tough for many organizations. > 10) If the Vendor is aware of other vendors that share the same > codebase as the affected product, then the Vendor MUST either (1) > notify those vendors, or (2) notify a Coordinator that other Vendors > may be affected by the reported vulnerability. Should all vendors be able to sponge off a few responsible vendors? What about anti-trust issues? Are you turning all vendors into de facto coordinators? If Vendor A notifies Vendor B about a problem, but vendor B chooses to ignore it, will Vendor A be willing to rat out Vendor B? I think having a coordinator involved in any multi vendor problem is valuable. > 1) The Reporter SHOULD work with the Vendor in a timely fashion to > explain the vulnerability and conduct further analysis. Why? Isn't that why people pay for software in teh first place, so that vendors will fix the problems? As a consumer of commercial software, it seems onerous to have to do testing in addition to paying for the software and an expensive maintenance contract. Now granted, most people would be willing to work with their vendors, but this seems to imply that they ought to. > 2) If the Vendor does not understand the nature, risk, or resolution > of the vulnerability, then the Reporter or involved Coordinators > SHOULD provide the Vendor with resources that help to explain the > vulnerability. This too seems to let the vendors off the hook a bit. Again, many people would say that this is what maintenance agreements are for. > 5) The Reporter SHOULD grant time extensions to the Vendor if there > is evidence that the Vendor is acting in good faith to resolve the > vulnerability. Time extensions to what? > 1) The Coordinator MUST attempt to resolve any conflicts or technical > disagreements that arise between the Reporter and the Vendor. Too broad. Coordinators have no responsibility to resolve "any" conflicts. Conflicts often center around issues like supported software, access to source code, licensing issues, access to beta software, direct access to engineers, etc, etc. ad naseum. > 1) The Vendor MUST identify the fundamental nature of the flaw within > the source code or in the design of the product ("Diagnosis"). Why? From many vendors' perspective, the less said about the cause of the problem, the better. I believe there is value to the research and educational community in knowing about the nature and frequency of the cause of vulnerabilities, but many organizations (customers in this case) would PREFER that their vendors be quiet about the cause of the problem. > 3) The Vendor SHOULD request time extensions from the Reporter and > involved Coordinators when necessary. Time extensions to what? There is an implicit assumption that if the vendor doesn't do X, then the reporter will DO SOMETHING. But what is that? Release an exploit? > 1) The Vendor SHOULD work with the Reporter and involved Coordinators > to arrange a date after which the vulnerability information may be > released. > > 2) The Vendor MAY ask the Reporter and Coordinator to allow a "Grace > Period" up to 30 days, during which the Reporter and Coordinator do > not release details of the vulnerability that could make it easier > for hackers to create exploit programs. I'm confused here. When does the information get released? What sorts of things *could* be released during the grace period? > 5) After the Grace Period, the Reporter MAY release additional > details. The Reporter SHOULD carefully consider how much detail is > needed by Customers and the Security Community. When is the first release of information? > 1) The Coordinator SHOULD work with the Vendor and Reporter to > arrange a date after which the vulnerability information may be > released. Which set of vulnerability information? There seems to be 2 kinds. > 4) If a Reporter has properly followed the process, then the Vendor > MUST provide credit to that reporter. What if the reporter doesn't want it? Many reporters prefer (and some are even required) to remain anonymous. > > 5) If a Coordinator has properly followed the process, then the > Vendor SHOULD provide credit to the Coordinator. Why the weaker standard for coordinators? > 6) If a Reporter has not properly followed the process and publicly > announces the vulnerability, then the Vendor MAY provide credit to > the reporter. This seems to imply that the vendor may choose not to credit someone if they don't follow the process, and that smacks to me of plagiarism. If a reporter chooses to assert his or her intellectual property rights, then I cannot support a BCP that allows vendors to ignore those rights. Indeed, I don't think the Provost of CMU would let me. A vendor may choose to label a person or group as irresponsible, stupid, or outright malicious, but should not be able to violate basic academic integrity standards by hiding behind a BCP. The "credit" is not the vendor's to withhold. > 8) The Vendor SHOULD cryptographically sign all patches using a > method that is commonly accessible on the platforms for the Vendor's > product. The Vendor should clearly advertise its cryptographic key > and provide cryptographic checksums for its patches. In general, I think any BCP in this arena ought to talk more extensively about the use of secure communication channels, particularly between coordinators and vendors. If you don't want a vulnerability disclosed, you shouldn't send it in plain text email. > If the Vendor has released information regarding the > vulnerability, then the Customer SHOULD assume that the information > is credible. The Customer SHOULD NOT require that the vulnerability > be demonstrated before applying the resolution. What if the vendor disclaims the vulnerability? Should the customer assume that if a vendor says their products aren't vulnerable that its true? In general, I think that the relevant point here is that you can be reasonably sure that if a vendor acknowledges a vulnerability, then there is a vulnerability. If someone you trust says there's a vulnerability, then you're probably best off believing them. The point about not requiring demonstration is good (and should be more carefully considered regarding the "reproduction" comment above). But what about when two trustworthy parties disagree? See for example http://www.cert.org/advisories/CA-2000-12.html and > 7) The Customer SHOULD give preference to products whose Vendors > follow responsible disclosure practices. What about vendors who build more secure products in general? :-) > 1) The Security Community SHOULD publicly recognize all Vendors, > Reporters, and Coordinators who follow responsible vulnerability > disclosure. You mean like a banquet? :-) > 2) The Vendor SHOULD NOT re-release the same advisory for newly > discovered, closely related vulnerabilities. If new action needs to be taken what choice do they have? I'm missing the point of this. Again, I applaud the effort, and I hope these comments are taken in the spirit in which they're intended. Thanks, Shawn From coley@linus.mitre.org Thu Feb 21 18:01:55 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA19796 for ; Thu, 21 Feb 2002 18:01:55 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA16667 for ; Thu, 21 Feb 2002 18:01:55 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1LKs0820518 for ; Thu, 21 Feb 2002 15:54:00 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1LKrxk17394 for ; Thu, 21 Feb 2002 15:53:59 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id PAA08555; Thu, 21 Feb 2002 15:49:24 -0500 (EST) Date: Thu, 21 Feb 2002 15:49:24 -0500 (EST) Message-Id: <200202212049.PAA08555@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: jericho@attrition.org CC: saag@mit.edu Subject: [saag] Re: Responsible Disclosure finally an Internet-Draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >> = me > = security curmudgeon >>[a "security" alias] still could require a process change on the part >>of vendors, i.e. training their physical security people to >>recognize security reports. (On the other hand, so might a secalert >>alias, especially for Vendors who haven't established a Security >>Response Capability yet). >Correct. A guard who handles physical security should be able to >quickly identify such mail. First, it comes from "that net thing" >instead of someone from the company they guard. Second, it deals with >all stuff not doors, turnstyles, walls, gates, etc. If their security >can't pick out the difference between the two.. =) True. I'll try to do more research on the intentions for the "security" alias; RFC2142 says it's for "Security bulletins or queries," which seems to leave some room for interpretation. (Is it a *source* address for vendors who send out bulletins? An alias for customers to use when subscribing to bulletin mailing lists? For reporting specific computer security incidents such as scanning activity?) >Instead of working so hard to create guidelines for the freaks (read: >people with handles or odd names) to use to reach a vendor, simply >demand that vendors not discriminate against those who wish to remain >anonymous, or use a handle. It is *very* well proven that they can be >qualified to do vuln research. > >[snip, snip, snip] > >for the first contact, the vendors need to be open to the idea that >despite their name, and despite their grasp of the english language, >they may be on top of things. It'll be interesting to see if I can add this while drastically shrinking the document as recommended by others ;-) though maybe another bullet could be added to 3.3.1: 8) The Vendor SHOULD treat incoming reports from unknown reporters as credible, until proven otherwise. Maybe it's a little too pithy, but it leaves room for the vendor to deal with incoming reports from *known* reporters as they wish. >> A larger problem is that without peer review or "certification" for >> reporters, it's difficult for a vendor to tell about someone's >> credibility at face value. > >True. But a reasonably well formed e-mail that explains a bug/vuln >should stand as just that. Our "sister document" on advisory contents will cover initial notification as well as public release. Reporters who follow the recommendations (or use a template) will gain credibility while simultaneously helping the vendor to validate the issue. >> 6) If the Vendor is unresponsive or disagrees with the Reporter's >> findings, then the Reporter SHOULD attempt to involve a >> Coordinator. >> >> (I added "attempt to"). > >This is good. Is it out of line or inappropriate for an RFC to give >details such as where to look or ask for one? ie: Can the RFC suggest >they seek out a Coordinator on Bugtraq, Vulnwatch, etc? My take on things, based on other RFC's I've read and probably some IETF or RFC Editor guidance somewhere, is that you should try to avoid specifics that could change over time. This is why various coordinators were not explicitly named. But maybe the coordinator definition is too vague. I don't think of Bugtraq or Vulnwatch as coordinators per se; they are "publications" (albeit mailing lists). It's the moderators of such lists who may act as coordinators (e.g., Russ Cooper of NTBUGTRAQ, SecurityFocus VulnHelp service) as well as organizations like CERT/CC. Thanks, - Steve From coley@linus.mitre.org Thu Feb 21 18:14:06 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA20035 for ; Thu, 21 Feb 2002 18:14:06 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA16163 for ; Thu, 21 Feb 2002 18:14:05 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1LMIb825279 for ; Thu, 21 Feb 2002 17:18:47 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1LMIak25975 for ; Thu, 21 Feb 2002 17:18:36 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id RAA16312; Thu, 21 Feb 2002 17:14:08 -0500 (EST) Date: Thu, 21 Feb 2002 17:14:08 -0500 (EST) Message-Id: <200202212214.RAA16312@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: shalunov@internet2.edu CC: saag@mit.edu Subject: Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Stanislav Shalunov said: >While having a BCP that describes vulnerability reporting guidelines >could be useful, the current version of the document could be improved >if it were made much more concise and somewhat less formal. The length and the formal nature of the document are known concerns. Interestingly, though, some comments I've received say "more MUSTs and less SHOULDs" and the like, so the formal language is showing to be useful for efficient commentary. >The sheer length of the document is overwhelming. The amount of >detail and motivation might be appreciated in an essay, but 27 pages >to specify a few simple rules is simply too much... The discussion >that leads to their establishment should probably not be included in >the final product. Perhaps a different approach would be to write an essay that goes into detail regarding all the different approaches, make sure the essay gets wide distribution (another Bugtraq post should do the trick ;-), then reference the essay in a slimmer document. >The rules themselves (mostly) make sense. Some people have found "holes" in how the different responsibilities, interactions, and timelines interact, which suggests that the current process may be too complicated. A process diagram might help. However, I think that we should be careful about simplifying *too* much. Some people summarize disclosure in 3 sentences, but the actual implementation of responsible disclosure isn't always so simple. >The URLs will rot. Agreed, but for now they make it easy for people to get to some of the previous work that led to this Internet-Draft. >Everything in this section is fine, but does it help to know the >authors' (or the IETF's) view of motivations of different parties to >follow the suggested process? I think it helps by showing why the current situation is so volatile, and it helps to explain why certain recommendations are made. >Maybe this discussion could be shortened and embedded in definition of >roles. Possibly, or it could be ommitted and placed into the "issues" document, if it's decided that such a document is useful. >> 1.4 Goals of Responsible Disclosure >This, again, seems too lengthy. As you may know, "responsible disclosure" as a phrase has been used heavily in the security industry for the last year or two. But it has also been used in different ways. These goals clarify what we mean. This touches on the usage of standardization language in this I-D. It's not explicitly stated, but the thinking is: "Someone who agrees with the goals of responsible disclosure MUST adhere to the key words specified in this document." i.e., there are specific expectations for any individual or organization who wants to say that they practice responsible disclosure. >> 1) The Vendor SHOULD ensure that programmers, designers, and testers >> are knowledgeable about common flaws in the design and implementation >> of products. > >What does it have to do with vulnerability reporting? If vendors had knowledgeable programmers/etc., then there wouldn't be as much vulnerability reporting. If you'd like a more specific answer: sometimes vendors do not even understand a vulnerability report. This has been a common complaint. In fact, just a week ago, I attempted to contact a vendor and ask them about the status of a reported vulnerability. An exploit tool was even apparently posted. The vendor's response was: "what [problem]? ... Many companies and governmental companies are using the software without any problem." Perhaps I made the mistake of not pointing the person *directly* to the *exploit* tool, rather just to the report (which contained a link to the exploit), but the vendor's response is unfortunately all too common. Alas, I had to send the email to tech support. They had no security contact. The vulnerability was publicly reported in Summer 2001. Obviously this is just a single case, but many reporters have had a similar experience. >> 2) Customers SHOULD configure their products and systems in ways that >> eliminate latent flaws or reduce the impact of latent flaws, > >What does this generic (and sound) advice have to do with >vulnerability reporting? 1) If a vulnerability is reported irresponsibly - say, with fully functioning exploit code - and the vendor hasn't had time to make a patch, then there is a possibility that the customer will be "safe" from the vulnerability (or at least the risk will be reduced.) As Russ Cooper points out, Code Red and Nimda would not have been so successful if people had configured IIS according to Microsoft's recommendations. 2) If a vulnerability is reported responsibly, then the customer may have more flexibility in deciding how to apply the resolution within their own enterprise... or they might not need to do anything at all. >> 3) The Security Community SHOULD track all known vulnerabilities to >> identify new classes of vulnerabilities, > >How can you require anything of a large loosely-knit community of >individuals? The requirements are to be for individual parties. We decided to highlight "Security Community" because they are a special class of consumers of vulnerability information. They are often times the providers of information - e.g. through weekly vulnerability summaries, or their own discoveries. They often create the tools that help people to secure themselves. They are often the first ones to realize when a new type of problem crops up. They could be the ones who could produce the information that allows customers to decide which product is "more vulnerable" than another. Basically, they have special needs for vulnerability information that is different than most customers or sysadmins need (or want). >> 1) The Reporter SHOULD make a reasonable effort to ensure that: - the >> vulnerability is real - the process of getting the product into a >> known exploitable state is repeatable > >This sounds like heisenbugs aren't real bugs and shouldn't be >reported. ("heisenbug?" nice term!) I see what you mean. But the reporter should at least try to determine if it's a heisenbug or something that's repeatable. >> 2) The Vendor SHOULD establish a Security Response Capability (SRC) >> that consists of one or more individuals or groups that are >> responsible for responding to vulnerability reports, verifying >> vulnerabilities, releasing bulletins, etc. >Is this suggesting a business practice? So, a free software developer >needs to establish a "Security Response Capability (SRC)"? Or should >he just fix the bugs? An individual, free software developer who has a clear email address and responds to security vulnerabilities *is* a Security Response Capability, without calling it such. Hrmmm, I see that "Security Response Capability" isn't really defined this way. >And is it even the fucntion of this document to tell the developer to >fix the bugs? According to many posters to Slashdot, it is :-) But are you saying that there are times when a developer can decide *not* to fix a bug and still be responsible? >> 3) The Vendor SHOULD ensure that its staff knows how to recognize a >> reported security issue and direct it to the Security Response >> Capability. > >This sounds like more business practice advice. It's software practice advice. "Vendor" does not mean just commercial companies. >Is IETF about recommending business practices or making Internet >protocols? This Internet-Draft is apparently different than most best current practice documents in that it deals more with how organizations interact than with specific technical issues. It's up to the SAAG and the IETF to decide, not me :) >> 4) If the Vendor can control the e-mail addresses that it uses (e.g., >> it has its own domain name), then the Vendor SHOULD define and >> publish the "secalert" alias for use in vulnerability notification. > >Sounds like you want to amend section 3 of RFC2142. >If that's the case, then it should not be in this document. I'll look more closely at this. I believe that there are other RFCs (and possibly BCP's) who also suggest using the "security" alias for things other than bulletins. >> 5) If the Vendor operates a web site or other means of distributing >> information regarding its product, then the Vendor SHOULD create and >> publish a "security" page or folder that identifies how vulnerability >> reports should be made. The Vendor SHOULD make this page easy to >> find from other locations, such as a separate contact page or index. > >This looks like information representation design advice. Pretty much, but there's a good reason for it. If a reporter can't figure out who to contact, then they are more likely to just post to *Bugtraq in an attempt to force the vendor to respond, which puts all the vendor's customers at risk until the issue is resolved. See the article by Barbara Pease and me. We gave ourselves 20 minutes per web site to try to find security information. We often exceeded that amount before giving up in frustration amidst a chaos of links, tech support forms, pages dedicated to security product *features*, and gobs of KB articles. (We gave ourselves a 20 minute deadline but sometimes got so lost in a web site that we wound up spending much longer than 20 minutes before we realized that we had gone over our limit.) "An informal analysis of vendor acknowledgement of vulnerabilities" Steve Christey, Barbara Pease Bugtraq mailing list March 11, 2001 http://marc.theaimsgroup.com/?l=bugtraq&m=98438570915835&w=2 >> 6) The Vendor MUST provide a facility for individuals or >> organizations who are not Customers to report vulnerabilities. > >MUST here must mean that the Internet will break if this isn't done. >This shouldn't be the case at least for software that's not >network-related. I think that MUST here means "if the Vendor wants to claim that they are responsible, then they MUST do this." >This is the point in the document where I gave up reading. Why don't >you just say this (should fit on one page): > > Give the vendor a chance to work on a problem report before you > publish bug details. In your communication to the vendor specify > when you plan to release your information publicly. You should > allow the vendor an appropriate amount of time to fix the bug (not > less than two weeks unless the vulnerability is already being > actively exploited). I believe that the current practices are more complex than that. But with a separate "issues" paper, maybe the Responsible Disclosure Process can be trimmed down significantly. Thank you for your comments! Regards, - Steve From coley@linus.mitre.org Thu Feb 21 19:34:00 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA21285 for ; Thu, 21 Feb 2002 19:34:00 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA08184 for ; Thu, 21 Feb 2002 19:34:00 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1M0Xr811481; Thu, 21 Feb 2002 19:33:53 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1M0Xqk14382; Thu, 21 Feb 2002 19:33:52 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id TAA00461; Thu, 21 Feb 2002 19:33:51 -0500 (EST) Date: Thu, 21 Feb 2002 19:33:51 -0500 (EST) Message-Id: <200202220033.TAA00461@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: [saag] Re: Internet-Draft for "Responsible Disclosure Process" released Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: The following messages were sent to me by Theo de Raadt of OpenBSD. I am forwarding them to SAAG with his permission. He is not on this list. The messages are separated by "==========" characters. My answers are indented and prefaced by [SMC]. ==================================================================== From: Theo de Raadt To: "Steven M. Christey" Subject: Re: Internet-Draft for "Responsible Disclosure Process" released In-reply-to: Your message of "Wed, 20 Feb 2002 00:55:01 EST." <200202200555.AAA13785@linus.mitre.org> Date: Wed, 20 Feb 2002 17:36:53 -0700 Good job. Actually, that is extreme sarcasm. You have created a document which will be used in self-defense by vendors who make bad products and do not plan or budget for repairs or maintainance, and will scare product quality research hobbiests into just not even bothering to disclose what they already know (well, publically anyways...) That is all this will change. It is lawyer bait. Therefore, this document will become part of the problem. [SMC] I hope that, by outlining a repeatable process that reporters can follow, *and* getting it accepted by the larger community, that reporters are *less* likely to be criticized because they find a bug and try to report it. They will have a community-accepted document that shows it. As you may know, some reporters are threatened with legal action when they report an issue. I speak as project leader for an operating system group that has 6 years experience at fixing security products on a wide variety of architectures in oh, normally about an hour, sometimes as much as a day. And we do this for fun and for free. [SMC] While I agree that some patches, OSes, and applictions take much longer to fix than one would like, there are issues such as regression testing, addressing multiple versions, etc. that are not necessarily feasible in such a rapid fashion. Many open source vendors can take longer than a day to fix a security issue. I can't speak for vendors (despite the first sentence of this paragraph), but it would be nice if vendors could explain *why* it can take a long time to fix issues. (It would also be nice to know how OpenBSD can do it while guaranteeing reliability, but that's off topic.) [SMC] Section 4.1, "Vendor Policy," encourages vendors to be forthcoming about how long it takes them to fix problems. Customers can then decide "how long is too long." If we can do it without such a document to help us out, why do you need to give the big corporations such help? [SMC] There are many types of vendors who do not properly handle vulnerability information. Almost 50% of all items in the CVE list (3000+ vulnerabilities) are not acknowledged by the vendor. I wish I could break it down further, but I don't have that data. This I-D addresses more than just the "many vendors don't fix bugs quickly" problem. I sense that there is a great denial against the idea that these vulnerabilities are in fact just quality assurance issues which noone wishes to take responsibility for in a fast, or should I say expensive, way. [SMC] The first bullet of the "Latent Flaws" section tries to suggest this, but some people want to remove it. ==================================================================== From: Theo de Raadt To: "Steven M. Christey" cc: deraadt@cvs.openbsd.org Subject: Re: Internet-Draft for "Responsible Disclosure Process" released Date: Wed, 20 Feb 2002 18:16:51 -0700 [EDITED OUT REQUEST TO FORWARD EMAIL TO SAAG] Reading closely, it seems that some people involved in writing this document wish to control the tide of alerts... so that discoveries are are manageable. That should be done at home, before things get started, but no vendor really wants to invest the time in doing that. (Don't act as if they do; they are not. Period.) Simply put, this document will rally the community against and VILIFY vulnerability disclosers who do not follow this exact process. On the other side, the process is massively heavy-weight. [SMC] Others have suggested the same thing. As a result, vulnerability discoverers will simply not alert. They will simply just continue to tell their friends. They will not even post anonymously. [SMC] Reporters who want to do "the right thing," *and* know how to do it, will tell the vendor regardless of whether there's a document or not. Reporters who want to do "the right thing" but *don't* know how to do it, will have a document that suggests what to do. But equally importantly, it tells *vendors* that not only should they *fix* reported vulnerabilities, they should actually make themselves *accessible* to people who want to report vulnerabilities, and they should make an effort to work with the reporter and resolve the problem as quickly as possible. The approach taken in this document is clever: to destroy the ability for a publisher to easily get fame and credit within his community, because it is outweighed by attacks from the greater community who use this document as a measuring stick. Trust me; very few will go through a month long process for fame and credit. [SMC] There are reporters who can't wait for a month because of motivations such as "getting fame" and being the first to discover something. But if someone reports a vulnerability without at least trying to work with the vendor, then they are putting all of the vendor's customers, and that is not responsible. See, in my view, fame and credit is a perfectly valid carrot to hold out to a person who has information that I can use to fix a bug. [SMC] Agreed. I think that they should get even *more* credit for trying to work with the vendor first. I want these things to be public as fast as possible. [SMC] The question of timing is a difficult one. There are many mixed opinions on this. OpenBSD's customers/users may want a vulnerability reported as soon as it is found, but there is at least one case in which a reporter reported an OpenBSD problem "as fast as possible" - and erroneously: BUGTRAQ:20001005 OpenBSD xlock exploit http://marc.theaimsgroup.com/?l=bugtraq&m=97076307710763&w=2 [SMC] You quickly pointed out that this vulnerability had already been fixed for months. But had the reporter tried the responsible route, I suspect that OpenBSD would have shown that this was a rediscovery, and this issue would not have been re-publicized, which may have caused some users to have to re-research an issue that was already fixed. If the reporter had found a new issue, OpenBSD users would have been at risk between the time the Bugtraq post was made and the time a fix was available and publicly announced. (Of course the risk would extend until the admin actually applied the patch, but that's not OpenBSD's responsibility once the issue is public.) [SMC] Obviously this is one example and a year old at that, but if guidance is available, then maybe more people will follow it. It looks like these might be other examples: BUGTRAQ:20010614 OpenBSD 2.9,2.8 local root compromise URL:http://marc.theaimsgroup.com/?l=bugtraq&m=99253282825806&w=2 BUGTRAQ:20010602 Locally exploitable races in OpenBSD VFS URL:http://marc.theaimsgroup.com/?l=bugtraq&m=99167357024081&w=2 [SMC] Actually, this latter post is an interesting case. I can't tell from the OpenBSD 2.8, 2.9, or current change logs whether this problem was real. I searched for "security" and "VFS". I fully recognize that I may be in error. [SMC] I sincerely do not mean to criticize OpenBSD's laudable goal of achieving security right out of the box. I was bringing up these examples to show the current state of affairs. This document will therefore, I believe, effectively cause vulerability information to go back underground, much more effectively than any previous attempts at no-disclosure have tried. [SMC] This concern has been raised in other places. If a reporter doesn't want to follow the suggested procedures, there is nothing preventing them from doing so, just like there is nothing preventing someone from ignoring the "common sense" disclosure practices today. [SMC] However, I agree that the document should be written in a way that does not allow vendors to from using it to threaten or prevent reporters from releasing vulnerability information... provided they do it responsibly. And back underground is not were we want this information to go, is it. [SMC] Absolutely not. So I feel this document is rather flawed, in that it outlines the rules which a reporter MUST follow (you use SHOULD, but the public will always read MUST, because they search to blame) [SMC] Some people have commented about the use of requirements language. I agree that people will read a "SHOULD" as a "must" instead. and the public will punish the reporter instead of the vendor. [SMC] That is more likely to happen today, since there is no community-accepted document that basically says, "reporters are doing a service by finding and reporting vulnerabilities." To me... it is quite apparent why such a mistake was made in this document. There are vendors involved. [SMC] They were involved, but only 4 of the 13 people who were consulted for this Internet-Draft were vendors. (That's excluding the 2 authors). See the Acknowledgements of the Internet-Draft. One of the vendors was an open source vendor. The acknowledgements include major mailing list moderators and well-known reporters, "full disclosure" and "anti-disclosure" advocates alike. [SMC] It may surprise you to know that Chris Wysopal and I had planned a second round of consultation by a wider group before publishing an Internet-Draft. This group included you. However, the IETF said that the document should be moved to public review as soon as possible, so we canceled this second consultation in support of the open IETF process. (We were not aware that private consultation for writing an Internet-Draft draft required talking to area directors first. I am grateful for the contributors that we had, otherwise this document would have been more controversial than it already is.) At a minimum, please re-read the document and tone it down, so that at no time a question arises of the reporter doing anything wrong. [SMC] Agreed, if you mean "the reporter is not doing anything wrong by letting the public know that an issue exists, after at least *trying* to work with the vendor to fix the issue." I truly appreciate your comments, Theo, despite our disagreements. Thanks, - Steve From svh@cert.org Thu Feb 21 23:25:00 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA24303 for ; Thu, 21 Feb 2002 23:25:00 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA02007 for ; Thu, 21 Feb 2002 23:24:59 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.65) with ESMTP id XAA29705; Thu, 21 Feb 2002 23:24:57 -0500 (EST) Received: from holmes.blue.cert.org (holmes.blue.cert.org [192.88.210.122]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id XAA11327; Thu, 21 Feb 2002 23:24:58 -0500 (EST) Date: Thu, 21 Feb 2002 23:24:57 -0500 (EST) From: Shawn Hernan X-X-Sender: svh@holmes.blue.cert.org To: aleph1@securityfocus.com, Subject: Re: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process In-Reply-To: <20020221082930.GA24687@securityfocus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Elias makes some excellent points. On Thu, 21 Feb 2002 aleph1@securityfocus.com wrote: > You have > opted to minimize the risk of the large population of non-technical users > at the short-term expense of technical users. I am not arguing whether > this is right or wrong, just that you need to point out the biases > in the selected process. This document makes an assumption and it needs > to be spelled out. Very true, and there are some other implicit assumptions that may bear some consideration. For example, does the document assume that all sites are equal, and that "disclosure" necessarily is a single event? What about sharing information with sponsors, clients, and customers? Should coordinators and vendors be required to disclose with whom they share information prior to public release and under what circumstances? Should a reporter be required to tell a vendor or coordinator who knows about the problem? Is anyone required to report incidents involving the vulnerability to anyone else? Is anyone required to take steps to prevent disclosure of a vulnerability under any circumstances? > The document also make no provisions for situations that may require > the reporter to disclose early such as when the vulnerability is > being exploited in the wild, when waiting for a vendor fix would > be more damaging than warning users early (e.g. to stop them from using > the dangerous feature), or when this whole process is almost never follwed > (e.g. academic publishing of flaws in a design such as IPsec or 802.11). Both very good points. I'm not sure I can imagine a circumstance under which active exploitation of a vulnerability isn't cause to disclose it. Shawn From DEndler@iDefense.com Fri Feb 22 14:56:50 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA05375 for ; Fri, 22 Feb 2002 14:56:50 -0500 (EST) Received: from idsrv10.idefense.com (user242.idefense.com [63.117.254.242] (may be forged)) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19775 for ; Fri, 22 Feb 2002 14:56:50 -0500 (EST) Message-ID: From: David Endler To: saag@mit.edu Subject: Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt Date: Fri, 22 Feb 2002 14:50:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBDA.2FF84930" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBDA.2FF84930 Content-Type: text/plain; charset="iso-8859-1" Greetings. I have to say that while the document does seem to lean on the side of vendors, that nothing within it seems ridiculously unreasonable or unfair to a reporter. It's unfortunate there are no such laws or standards for vendor resolution of vulnerabilities, which understandably stacks the cards in their favor with this document. I would love to see a companion document with even more details on the software development lifecycle responsbilities of vendors responding to security vulnerabilities (i.e. timeliness of response team, QA team testing, regression testing of patches, etc.). Regardless, those in the "security community" who feel this standard is too strict or are proponents of true FULL disclosure will undoubtedly still disclose flaws in much the same way they have been doing. Unlike Theo, I do not think this document will drive security researchers away from public disclosure; if anything, it just consolidates and formalizes the practices of only those who *wish* to disclose responsibly (semi-full, etc.). I also absolutely agree with Elias, the point needs to be made that there is an implicit trade-off assumed with following this process. By keeping silent to the technical majority a meaty vulnerability, there may already be active exploitation to which a very simple workaround could have been publically shared to prevent damage. Additionally, I would also echo the sentiments of others to offer aditional provisions for exceptional sitations in the process such as: *Evidence of active exploitation, go ahead and disclose anyway? *Some form of dispute resolution process (everything so far assumes cooperation and love abound between reporters and vendors, not sure who would mediate). right now, the only hazy statement refers to " 7) If the Reporter is unresponsive or uncooperative, or a dispute arises, then the Vendor SHOULD work with a Coordinator to identify the best available resolution for the vulnerability. " *Contingencies for the reporter at each stage if the vendor refuses or fails to abide by their assumed responsibilities (assuming no dispute process occurs) >A Coordinator is an individual or organization who works with the >Reporter and the Vendor to analyze and address the vulnerability. >Coordinators are often well-known third parties. Coordinators may >have resources, credibility, or working relationships that exceed >those of the reporter or vendors. Coordinators may serve as proxies >for reporters, help to verify the reporter's claims, resolve >conflicts, and work with all parties to resolve the vulnerability in >a satisfactory manner. Note: while Coordinators can facilitate the >responsible disclosure process for a vulnerability, the use of >Coordinators by other parties is not a requirement. The identity of the Corrdinator is rather vague, perhaps purposely so? I assume this can be a recognized security figure, another vendor, my dog, etc.? I assume that there is an implied NDA between the Coordinator and the Reporter? This should be explicitly stated, unless it's deemed ok for the Coordinator to forward it on to 3 more Coordinators, and they'll forward it to 5 of their Coordinator friends, etc. >Vendors may have one or more of the following motivations. Some >vendors believe that public notification may help their customers >address vulnerabilities, at the possible cost of negative publicity. >Some vendors may be unresponsive, or secretly fix vulnerabilities, >for fear of negative publicity. Some vendors may not have the >technical skills to understand the nature of the vulnerability and >the risk that it poses. Also, some vendors may not have the money to spend on diagnosis and distribution of a patch. Some vendors may not even exist anymore, what then? Should the disclosure process include going to a Meta-Vendor or Coordinator, someone who can develop a patch just as easily but may not be directly associated with the product? >2) Minimize the risk to customers from vulnerabilities that could > allow damage to their systems. Maybe change to ". . .allow damage directly or indirectly." here. For instance, someone hacking in or DoSing my ISP's routers will not directly affect my system, but will cost me $$$ in lost business, etc. >1) Latent Flaw. A flaw is introduced into a product during its > design, specification, development, installation, or default > configuration. Flaws can also be introduced by integrating one or more technologies together improperly, where neither of them independently may involve a vulnerability. > 4) If a Reporter has properly followed the process, then the Vendor > MUST provide credit to that reporter. > > 5) If a Coordinator has properly followed the process, then the > Vendor SHOULD provide credit to the Coordinator. I would say credit should be given as the Reporter/Coordinator wishes. R/C may wish to remain anonymous, be associated with their company, NOT be associated with their company, etc. > 4) If a Vendor requests a Grace Period, then the Reporter SHOULD > follow the Grace Period before releasing details of the > vulnerability. > 2) If the Vendor requests a Grace Period, the Coordinator SHOULD > follow the Grace Period and encourage the Reporter to follow the > Grace Period. Agree with Elias' comment here, substitute SHOULD for MAY, there's no way to predict if the vendor is being reasonable here. This is a great effort, kudos to all involved thus far. Just a few early comments, I'm sure I'll have more :-) -dave David Endler, CISSP Director, iDEFENSE Labs 14151 Newbrook Drive Suite 100 Chantilly, VA 20151 voice: 703-344-2632 fax: 703-961-1071 dendler@idefense.com www.idefense.com ------_=_NextPart_001_01C1BBDA.2FF84930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt

Greetings.

I have to say that while the document does seem to = lean on the side of vendors, that nothing within it seems ridiculously = unreasonable or unfair to a reporter.  It's unfortunate there are = no such laws or standards for vendor resolution of vulnerabilities, = which understandably stacks the cards in their favor with this = document.  I would love to see a companion document with even more = details on the software development lifecycle responsbilities of = vendors responding to security vulnerabilities (i.e. timeliness of = response team, QA team testing, regression testing of patches, = etc.).

Regardless, those in the "security = community" who feel this standard is too strict or are proponents = of true FULL disclosure will undoubtedly still disclose flaws in much = the same way they have been doing.  Unlike Theo, I do not think = this document will drive security researchers away from public = disclosure;  if anything, it just consolidates and formalizes the = practices of only those who *wish* to disclose responsibly (semi-full, = etc.).

I also absolutely agree with Elias, the point needs = to be made that there is an implicit trade-off assumed with following = this process.  By keeping silent to the technical majority a meaty = vulnerability, there may already be active exploitation to which a very = simple workaround could have been publically shared to prevent = damage.  

Additionally, I would also echo the sentiments of = others to offer aditional provisions for exceptional sitations in the = process such as:

        *Evidence = of active exploitation, go ahead and disclose anyway?

        *Some form = of dispute resolution process (everything so far assumes cooperation = and love abound between reporters and vendors, not sure who would = mediate).  right now, the only hazy statement refers to =

        =         " 7) If the Reporter is = unresponsive or uncooperative, or a dispute arises, then the Vendor = SHOULD work with a Coordinator to identify the best available = resolution for the vulnerability. "

        *Contingencies for the reporter at each stage if the vendor = refuses or fails to abide by their assumed responsibilities (assuming = no dispute process occurs)


>A Coordinator is an individual or organization = who works with the
>Reporter and the Vendor to analyze and address = the vulnerability.
>Coordinators are often well-known third = parties.  Coordinators may
>have resources, credibility, or working = relationships that exceed
>those of the reporter or vendors.  = Coordinators may serve as proxies
>for reporters, help to verify the reporter's = claims, resolve
>conflicts, and work with all parties to resolve = the vulnerability in
>a satisfactory manner.  Note: while = Coordinators can facilitate the
>responsible disclosure process for a = vulnerability, the use of
>Coordinators by other parties is not a = requirement.

The identity of the Corrdinator is rather vague, = perhaps purposely so?  I assume this can be a recognized security = figure, another vendor, my dog, etc.?  I assume that there is an = implied NDA between the Coordinator and the Reporter?  This should = be explicitly stated, unless it's deemed ok for the Coordinator to = forward it on to 3 more Coordinators, and they'll forward it to 5 of = their Coordinator friends, etc.



>Vendors may have one or more of the following = motivations.  Some
>vendors believe that public notification may = help their customers
>address vulnerabilities, at the possible cost of = negative publicity.
>Some vendors may be unresponsive, or secretly = fix vulnerabilities,
>for fear of negative publicity.  Some = vendors may not have the
>technical skills to understand the nature of the = vulnerability and
>the risk that it poses.
       =20
Also, some vendors may not have the money to spend = on diagnosis and distribution of a patch.  Some vendors may not = even exist anymore, what then?  Should the disclosure process = include going to a Meta-Vendor or Coordinator, someone who can develop = a patch just as easily but may not be directly associated with the = product?


>2) Minimize the risk to customers from = vulnerabilities that could
>   allow damage to their systems. =

Maybe change to  ". . .allow damage = directly or indirectly." here.  For instance, someone hacking = in or DoSing my ISP's routers will not directly affect my system, but = will cost me $$$ in lost business, etc.


>1) Latent Flaw.  A flaw is introduced into a = product during its
>   design, specification, development, = installation, or default
>   configuration.

Flaws can also be introduced by integrating one or = more technologies together improperly, where neither of them = independently may involve a vulnerability. 


>   4) If a Reporter has properly = followed the process, then the Vendor
>   MUST provide credit to that = reporter.
>
>   5) If a Coordinator has properly = followed the process, then the
>   Vendor SHOULD provide credit to the = Coordinator.

I would say credit should be given as the = Reporter/Coordinator wishes. R/C may wish to remain anonymous, be = associated with their company, NOT be associated with their company, = etc.

>    4) If a Vendor requests a = Grace Period, then the Reporter SHOULD
>    follow the Grace Period = before releasing details of the
>    vulnerability.


>    2) If the Vendor requests a = Grace Period, the Coordinator SHOULD
>    follow the Grace Period and = encourage the Reporter to follow the
>    Grace Period.

Agree with Elias' comment here, substitute SHOULD for = MAY, there's no way to predict if the vendor is being reasonable = here.

This is a great effort, kudos to all involved thus = far.


Just a few early comments, I'm sure I'll have more = :-)

-dave

David Endler, CISSP
Director, iDEFENSE Labs
14151 Newbrook Drive
Suite 100
Chantilly, VA 20151
voice: 703-344-2632
fax: 703-961-1071

dendler@idefense.com
www.idefense.com

------_=_NextPart_001_01C1BBDA.2FF84930-- From aleph1@securityfocus.com Fri Feb 22 15:15:41 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA05676 for ; Fri, 22 Feb 2002 15:15:41 -0500 (EST) From: aleph1@securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id PAA28479 for ; Fri, 22 Feb 2002 15:15:40 -0500 (EST) Received: (qmail 5425 invoked by uid 101); 22 Feb 2002 20:14:27 -0000 Date: Fri, 22 Feb 2002 13:14:27 -0700 To: saag@mit.edu Subject: Re: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Message-ID: <20020222201427.GC1081@securityfocus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This is another error in this document. Steve said: > This touches on the usage of standardization language in this I-D. > It's not explicitly stated, but the thinking is: > > "Someone who agrees with the goals of responsible disclosure MUST > adhere to the key words specified in this document." > > i.e., there are specific expectations for any individual or > organization who wants to say that they practice responsible > disclosure. The corollary to this statement is that anyone that does not follow the process in this document is then "irresponsible". Since when is the IETF is the business of dictating morals? As I mentioned in my last message some people may have a very different idea of what is "responsible". For example, I don't particularly find "responsible" that CERT provides vulnerability information to companies that pay for access while the public has to wait[1]. (No offense Shawn) While the authors of this document and other may wish to make their idea of disclosure the "best current practice", labeling people that do not follow it as irresponsible and use the IETF weight to give that label legitimacy is wrong. The document needs to be renamed and a new term be used to describe what this document terms "responsible disclosure". [1] http://www.isalliance.org/ -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum From OgleR@thmulti.com Fri Feb 22 15:38:12 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA06032 for ; Fri, 22 Feb 2002 15:38:12 -0500 (EST) Received: from ns1.thmulti.com (ns1.thmulti.com [141.11.234.67]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA07016 for ; Fri, 22 Feb 2002 15:38:11 -0500 (EST) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id VAA01439; Fri, 22 Feb 2002 21:38:09 +0100 (MET) Received: from parexch3.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id VAA28874; Fri, 22 Feb 2002 21:38:09 +0100 (MET) Received: by parexch3 with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 21:38:34 +0100 Message-ID: <05B4910E0216D411B14F00508B6A67A9029419D5@RENEXCH5.rennes.thmulti.com> From: "Ogle Ron (Rennes)" To: "'aleph1@securityfocus.com'" , saag@mit.edu Subject: RE: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Date: Fri, 22 Feb 2002 21:38:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: It is very ironic that this document is trying to create an ethical code by which vulnerability practitioners are going to be expected to abide by; however, there is no such IETF document that describes how software developers are suppose to design "responsible" systems or write "responsible" code. It seems that maybe there should be a group of documents that are created out of this need to have more secure systems. If the IETF (SAAG) is going to start supporting these endeavors as they seem to be doing, then a proper working group should be assembled with the proper scope. I'd suggest that the scope would be something along the line of "best practices in designing, developing, testing, and supporting software based systems." Vulnerability disclosure would fall under supporting software based systems. We all know that security can't be bolted on after the fact. But here again, we are trying to solve a problem in the computer industry by bolting it on after the fact. If there wasn't such bad code out there, we wouldn't even be talking about this document. If the vendors really want "responsible" vulnerability reporting, then we want "responsible" designed, developed, and supported systems. My .02 Ron Ogle Rennes, France -----Original Message----- From: aleph1@securityfocus.com [mailto:aleph1@securityfocus.com] Sent: Friday, February 22, 2002 09:14 PM To: saag@mit.edu Subject: Re: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process This is another error in this document. Steve said: > This touches on the usage of standardization language in this I-D. > It's not explicitly stated, but the thinking is: > > "Someone who agrees with the goals of responsible disclosure MUST > adhere to the key words specified in this document." > > i.e., there are specific expectations for any individual or > organization who wants to say that they practice responsible > disclosure. The corollary to this statement is that anyone that does not follow the process in this document is then "irresponsible". Since when is the IETF is the business of dictating morals? As I mentioned in my last message some people may have a very different idea of what is "responsible". For example, I don't particularly find "responsible" that CERT provides vulnerability information to companies that pay for access while the public has to wait[1]. (No offense Shawn) From phoffman@imc.org Fri Feb 22 21:12:18 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA09987 for ; Fri, 22 Feb 2002 21:12:18 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA02201 for ; Fri, 22 Feb 2002 21:12:18 -0500 (EST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1N2CB318318; Fri, 22 Feb 2002 18:12:11 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200202220033.TAA00461@linus.mitre.org> References: <200202220033.TAA00461@linus.mitre.org> Date: Fri, 22 Feb 2002 18:12:10 -0800 To: "Steven M. Christey" , saag@mit.edu From: Paul Hoffman / IMC Subject: [saag] Re: Internet-Draft for "Responsible Disclosure Process" released Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: To echo what a few other people have said: why is this document so long? It sounds more like a white paper than short, crisp definition of Best Current Practices. Lots of the material is statements that are easy for Company A to agree with but Company B to disagree with, or Reporter C to agree with but Reporter D to disagree with. Suggestion: make it about five pages long. Name the parties, give a timeline template, list the timers, describe who can do what in the various failure states, and say "people will have different reasons for complying and not complying with this". --Paul Hoffman, Director --Internet Mail Consortium From svh@cert.org Fri Feb 22 21:56:26 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA10451 for ; Fri, 22 Feb 2002 21:56:26 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA06281 for ; Fri, 22 Feb 2002 21:56:25 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.65) with ESMTP id VAA23664; Fri, 22 Feb 2002 21:56:23 -0500 (EST) Received: from holmes.blue.cert.org (holmes.blue.cert.org [192.88.210.122]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id VAA11033; Fri, 22 Feb 2002 21:56:24 -0500 (EST) Date: Fri, 22 Feb 2002 21:56:24 -0500 (EST) From: Shawn Hernan X-X-Sender: svh@holmes.blue.cert.org To: aleph1@securityfocus.com cc: saag@mit.edu Subject: Re: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process In-Reply-To: <20020222201427.GC1081@securityfocus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > For example, I don't particularly find "responsible" that CERT provides > vulnerability information to companies that pay for access while the > public has to wait[1]. (No offense Shawn) None taken. Its a perfectly legitimate question about what "responsible" means, and illustrates the large gray area that exists among different groups who want to do the right thing (whatever that is). This document speaks to the group for whom these are relevant distinctions -- it does not speak to the groups who prefer to "disclose" vulnerabilities by compromise nor to the groups who would prefer that vulnerabilites remain burried forever. (To be accurate though, the ISA membership is considerably more than access to vulnerability information, but that's not germane to your point.) Shawn From shalunov@internet2.edu Fri Feb 22 23:16:50 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA11252 for ; Fri, 22 Feb 2002 23:16:50 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA14425 for ; Fri, 22 Feb 2002 23:16:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 5E24B5EE46; Fri, 22 Feb 2002 23:16:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 22AA75EDF3; Fri, 22 Feb 2002 23:16:35 -0500 (EST) To: "Steven M. Christey" Cc: saag@mit.edu Subject: Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt References: <200202212214.RAA16312@linus.mitre.org> From: stanislav shalunov Date: 22 Feb 2002 23:17:12 -0500 In-Reply-To: <200202212214.RAA16312@linus.mitre.org> Message-ID: <87ofigde7r.fsf@cain.internet2.edu> Lines: 143 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Steven M. Christey" writes: > Possibly, or it could be ommitted and placed into the "issues" > document, if it's decided that such a document is useful. That would work. > This touches on the usage of standardization language in this I-D. > It's not explicitly stated, but the thinking is: > > "Someone who agrees with the goals of responsible disclosure MUST > adhere to the key words specified in this document." This seems to only make it worse by essentially defining a formal meaning for the word "responsible" that many people will heatedly disagree with. > If vendors had knowledgeable programmers/etc., then there wouldn't > be as much vulnerability reporting. But what does it have with practices of reporting security vulnerabilities? This (and similar) advice seems to be out-of-place. > If you'd like a more specific answer: sometimes vendors do not even > understand a vulnerability report. And how would writing a document about disclosure protocol help? > We decided to highlight "Security Community" because they are a > special class of consumers of vulnerability information. But you require something of a class of people as a whole. Does person X (who might or might not consider himself part of the "Security Community") need to fulfill these requirements each and every time there's a security-sensitive bug reported? Surely not... For example, the "publicly recognize [...]" part is an activity that could involve a defending against a lawsuit after delisting some company, if there's a list of publicly recognized entities. This is basically along the lines of conformance certification for Internet standards *duck*. > ("heisenbug?" nice term!) http://www.tuxedo.org/~esr/jargon/html/entry/heisenbug.html > I see what you mean. But the reporter should at least try to > determine if it's a heisenbug or something that's repeatable. ...but probably report it anyway. This seems like more generic (bug-reporting, this time) advice. If you were to give bug-reporting advice, you'd need to make it much more complete. A lot of the stuff in, e.g., http://www.gnu.org/manual/emacs/html_chapter/emacs_36.html#SEC483 is generic. (Notice that I advocate removing all such advice rather than expanding it any further.) >> And is it even the fucntion of this document to tell the developer >> to fix the bugs? > > According to many posters to Slashdot, it is :-) I will not comment on this. > But are you saying that there are times when a developer can decide > *not* to fix a bug and still be responsible? In most other areas, IETF isn't in the business of dispensing advice and setting moral guidance. This document has enough controversial substance even without that... To answer your question, there might be different situation when not fixing something leads to a security problem would be considered OK by many people, just to name a few: * Software that's not maintained but provided for interested parties for free anyway; * Software that is documented to behave in an undefined way on inputs other than specified (e.g., a statistics package doesn't necessarily need to be scrutinized for format string bugs and buffer overflows in the code that reads numbers from data files; even though once you attach it to the net and allow strangers to feed arbitrary data to it you could have left your system open to hijacking); * Bugs in convoluted parts of freely provided software (written by someone who no more has interest in the program) that the current maintainer doesn't understand. But you yourself have the part that says "The Vendor MUST either [fix it or] provide the Reporter and involved Coordinators with specific reasons for its inaction" in section 3.6.1. > It's software practice advice. "Vendor" does not mean just > commercial companies. Note that the IETF currently doesn't provide any development practice advice even for software that only implements IETF networking standards. You haven't asnwer my question about how much time you expect to pass before an exploit for a problem is posted after it is first reported to a vendor that does nothing to fix it. My calculation seems to indicate that it is: 7 days before auto-response 10 days before clerical "looking into it" 30 days before "not done yet", with weekly "looking" 30 days of grace period 77 days before one can post an exploit in a case of a deadbeat vendor? Is this the intention or am I missing something? (And if I am, I guess you might wish to clarify the document.) ------------------------------------------------------------ A few more points: There seem to be no provisions for cutting corners in specific situations. I'm sure the least controversial case of full immediate disclosure in the case of vulnerabilities that are already being actively exploited is an oversight (maybe I simply couldn't find it?), but what about situations when the reporter had repeatedly bad experience with a particular vendor and has grounds to assume that the vendor is not acting in good faith when requesting delays and similar situations? After looking at this again, I find the document tilted too much to the point of view of vendors. Under no circumstances other than personal good will should one expect people who find bugs in software other people are paid to support to provide these people with free consultations. If the reporter feels so inclined, that's fine. If he doesn't want to get involved in understanding the subtleties of the bug he found, it's hardly irresponsible. "Coordinators" have rather rigid roles and quite vague definition. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Which one is worse? Both are worse." -- V. I. Lenin From Ken@infosec101.org Sat Feb 23 11:17:22 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA17753 for ; Sat, 23 Feb 2002 11:17:22 -0500 (EST) Received: from mail1.intermedia.net (mail1.intermedia.net [206.40.48.151]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA27575 for ; Sat, 23 Feb 2002 11:17:21 -0500 (EST) Received: from arrow1 (unverified [66.67.44.45]) by mail1.intermedia.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Sat, 23 Feb 2002 08:17:19 -0800 Reply-To: From: "Ken Pfeil" To: "Steven M. Christey" Cc: Subject: RE: [saag] draft-christey-wysopal-vuln-disclosure-00.txt Date: Sat, 23 Feb 2002 11:15:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <87ofigde7r.fsf@cain.internet2.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: One thing that I see noticably missing in this entire process is the "workaround" issue. It may be mentioned in passing, but more is needed. Granted, it may not always be possible to completely eliminate a bug from the codebase within 30 days, but surely the vendor can recommend a suitable workaround (configuration or otherwise) within a shorter timeframe that will help minimize the associated risks. Tying the hands of the discoverer (and reporter) for 77 days, while an active exploit floats around among "friends" is a bit much. Identifying this suitable workaround should NOT take 30 days. Notice that I categorized discoverer and reporter separately. Also, I consider 7 days for a vendor to acknowledge someone's existence, and that they ever received an email to be quite generous. If companies took 7 days to respond to a customer, that customer would probably take their business elswhere. Just my .002 (yes, not quite 2 cents) Ken From eddiealz@eudoramail.com Sat Feb 23 23:02:27 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA24555 for ; Sat, 23 Feb 2002 23:02:26 -0500 (EST) Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id XAA22562 for ; Sat, 23 Feb 2002 23:02:26 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Sat Feb 23 20:02:11 2002 To: saag@mit.edu Date: Sat, 23 Feb 2002 20:02:11 -0800 From: "Edward Alz" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: eddiealz@eudoramail.com X-Mailer: MailCity Service X-Sender-Ip: 24.128.190.214 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Subject: [saag] Re: Internet-Draft for "Responsible Disclosure Process" released Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > [SMC] Reporters who want to do "the right thing," *and* know how to > do it, will tell the vendor regardless of whether there's a document > or not. Reporters who want to do "the right thing" but *don't* know > how to do it, will have a document that suggests what to do. I disagree. I believe the main effect of a 27 page BCP (largely independent of exact details) is that many fewer people will report vulnerabilities. Take a typical person who reads vulnerability lists (bugtraq, vuln-dev, whatever). Maybe he's sent to those lists himself. None of this is work he's paid for. He'd probably know that there's now an explicit BCP metric by which other people can label him irresponsible/non-compliant/otherwise-bad. He'd probably feel some motivation to follow the BCP. Yet, the effort required is *substantial*. Just to start, he must find the time to read and understand a 27 page document of complex decision flow. My guess is that he simply won't get a round tuit. He also won't ever report the vulnerability. It will remain unfixed, and in some significant (not huge) fraction of cases, will eventually be rediscovered by someone with malicious intent. All in all, risk to typical Internet users from a single disclosure might be lower (since every vulnerability will be be disclosed "properly"). But the overall risk to typical Internet users, summed across all vulnerabilities, will be higher due to many vulnerabilities remaining unfixed longer. If a BCP is needed, I suggest that it instead describe how Vendors can provide better information to Reporters, so Reporters can carry out their "important role in enhancing Internet security" more effectively. Specifically: what type of reports will the vendor act on, how long will it take, and what else should the Reporter expect. Put the information at www.vendor_site.com/vulnerability_handling. Two hypotheticals: * vendor produces closed-source PC software * software should only be used within a well-isolated, well-monitored intranet (except for tcp ports open to web and mail servers) * wants reports about any type of vulnerability * all reports get an initial reply within 5 days; reporter can provide information about application failure, crashes, etc. but if exploitability is unknown, completion of a fix may take much longer * average fix time for remote access: 3 months * average fix time for remote DoS: 9 months * prior to public fix, vendor will provide a fix to: 100 largest customers, U.S. and many other governments, ISACs versus * vendor produces open-source PC software * the default installation is intended for Internet use * wants to receive reports about vulnerabilities except for local DoS and non-critical information leakage * the reporter can either demonstrate exploitability or point out the vulnerability in the source code; either of these will result in a quick reply, but other reports might not * average fix time for remote access: 36 hours * average fix time for remote DoS: 10 days * prior to public fix, vendor will provide a fix to: the vendor's security team and anyone else who bothers to check for new CVS commits Neither of these two is necessarily better. I think this would have two positive effects. First, it would make it less practical for a large company with a well-funded SRC to claim that other vendors were irresponsible. The binary distinction of responsible/irresponsible is gone. Customers can choose among vendors based on a richer description of vulnerability handling. Second, reporters don't waste time writing up vulnerability reports that a particular vendor does not care about. (In cases where the vendor does not care, the reporter might either choose to disclose immediately, or spend his time on something else.) --eddie Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From coley@linus.mitre.org Sun Feb 24 16:46:57 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA04514 for ; Sun, 24 Feb 2002 16:46:56 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA15304 for ; Sun, 24 Feb 2002 16:46:56 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1OLku817851; Sun, 24 Feb 2002 16:46:56 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1OLksk27178; Sun, 24 Feb 2002 16:46:54 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id QAA27108; Sun, 24 Feb 2002 16:46:54 -0500 (EST) Date: Sun, 24 Feb 2002 16:46:54 -0500 (EST) Message-Id: <200202242146.QAA27108@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: aleph1@securityfocus.com CC: saag@mit.edu Subject: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: In multiple posts, Elias Levy said: >> 1.4 Goals of Responsible Disclosure >> >> The goals of responsible disclosure include: >> >> 1) Ensure that vulnerabilities can be identified and eliminated >> effectively and efficiently for all parties. > >As you've mentioned before different parties can have conflicting >goals. You cannot ensure that vulnerabilities can be identified and >eliminated effectively and efficiently for all parties. It would be >better if you actually spelled out what balance have you struck. Good point. >by keeping vulnerability information secret while you wait for a >vendor fix you maintain at risk those that could do something to >minimize their risk without an official fix. You have opted to >minimize the risk of the large population of non-technical users at >the short-term expense of technical users. I am not arguing whether >this is right or wrong, just that you need to point out the biases in >the selected process. This document makes an assumption and it needs >to be spelled out. Yes, you make a good point. The document does focus on one particular mode of operating, and even though it tries to be flexible, there is still a primary "theme" that is not clearly described. >> 5) If the Vendor operates a web site or other means of distributing >> information regarding its product, then the Vendor SHOULD create and >> publish a "security" page or folder that identifies how vulnerability >> reports should be made. > >What about suggestion a canonical URL as you do for email? >e.g. /security Good point. http://www.example.com/security/ or, if the vendor doesn't own their own domain name, http://www.example.com/vendor-home/security.html >> 3) If the Vendor's receipt message is automatically generated, then >> it SHOULD include a time period or date by which an individual (or >> the Security Response Capability) will provide follow-up on the >> reported vulnerability. The time period SHOULD NOT exceed 10 days. > >10 days from when? notification or receipt? The next point makes it seem >notification but its better to be clear. The intention is 10 days from notification. >> 4) If a Reporter has properly followed the process, then the Vendor >> MUST provide credit to that reporter. > >What defines "properly"? The are a lot of shoulds in this document. >Only "musts" need to be meet for the process to have been done "properly"? Good point, "properly" needs to be spelled out. >> 4) If a Vendor requests a Grace Period, then the Reporter SHOULD >> follow the Grace Period before releasing details of the >> vulnerability. > >Here you are injecting your bias into the process. s/SHOULD/MAY/ > >> 2) If the Vendor requests a Grace Period, the Coordinator SHOULD >> follow the Grace Period and encourage the Reporter to follow the >> Grace Period. > >Ditto. s/SHOULD/MAY/ Here, I was trying to account for the relatively new suggestion that vendors could ask for a grace period. The pros and cons of this suggestion have not been discussed fully, and we haven't seen this practiced often enough to know how well it will work. If the notion of a grace period is more commonly used, then customers can decide whether the grace period is long enough for them. Some of the rationales for these points come from the hope that if such practices are requested by vendors *and* publicized (e.g. in the vendor policies as referenced elsewhere in the document), then it becomes easier for customers to pick and choose which vendors are sufficiently responsive for their needs. Reporters who want to help customers while balancing it with how the vendor does business can follow a vendor's posted policy and let the public decide. The policies would be like a labeling system for smart shoppers, in which some of the terminology is defined in this document. >> "Someone who agrees with the goals of responsible disclosure MUST >> adhere to the key words specified in this document." >> >> i.e., there are specific expectations for any individual or >> organization who wants to say that they practice responsible >> disclosure. > >The corollary to this statement is that anyone that does not follow >the process in this document is then "irresponsible". Since when is >the IETF is the business of dictating morals? As I mentioned in my last >message some people may have a very different idea of what is "responsible". > >For example, I don't particularly find "responsible" that CERT provides >vulnerability information to companies that pay for access while the >public has to wait[1]. (No offense Shawn) > >While the authors of this document and other may wish to make their idea >of disclosure the "best current practice", labeling people that do not >follow it as irresponsible and use the IETF weight to give that label >legitimacy is wrong. The document needs to be renamed and a new term >be used to describe what this document terms "responsible disclosure". This is an important point, but I think that a line in the sand needs to be drawn *somewhere*. As you and others have indicated, though, this document is still too rigid in moving everyone down a single path, despite the large number of "SHOULDs." Maybe a new term could be used. "Coordinated disclosure" is probably more descriptive of what this document is talking about, though there is an unfortunate overlap with the "coordinator" role. >My main objection to the draft is that, while Steve agrees that no one >set of time tables can apply to all situations, the process defines >gives vendors a minimum of 30 days to clean up their act. That may be >proper is most cases but not all. As you and others have pointed out, one of the biggest reasons for releasing more quickly is when a problem is being actively exploited in the wild. This issue is alluded to in the References section, but it is not explicitly mentioned. You mentioned some other scenarios in which a shorter time frame is important. It would probably be good to specifically mention these considerations in the Release Phase section. Thanks, - Steve From coley@linus.mitre.org Sun Feb 24 16:58:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA04649 for ; Sun, 24 Feb 2002 16:58:34 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA10525 for ; Sun, 24 Feb 2002 16:58:34 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1OLwY818393; Sun, 24 Feb 2002 16:58:34 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1OLwXk27919; Sun, 24 Feb 2002 16:58:33 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id QAA27284; Sun, 24 Feb 2002 16:58:32 -0500 (EST) Date: Sun, 24 Feb 2002 16:58:32 -0500 (EST) Message-Id: <200202242158.QAA27284@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: jericho@attrition.org CC: saag@mit.edu Subject: [saag] Re: Responsible Disclosure finally an Internet-Draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: security curmudgeon said: >> I'll try to do more research on the intentions for the "security" >> alias; RFC2142 says it's for "Security bulletins or queries," which >> seems to leave some room for interpretation. > >Yeah, 2142 is a bit vague there. I don't know the procedure/etiquette >on building on or clarifying other aliases, but I think it would be >appropriate if you guys would clear this up for them when you define >the accepted alias for reporting bugs. I have sent an email to the author of RFC 2142 requesting guidance. I'll let you know if I get a response. >> Our "sister document" on advisory contents will cover initial >> notification as well as public release. Reporters who follow the >> recommendations (or use a template) will gain credibility while >> simultaneously helping the vendor to validate the issue. > >Has a draft of this been released? I haven't seen it yet (sounds liek it >is in the works). Either way, that is another document that clearly needs >to be written. Chris and I are presently concentrating on the process document, which is the least controversial. (Note the lack of smilies in that last sentence. We won't be able to avoid the question of exploit details in the advisory contents document). We are thinking about this document, but we don't even have an outline at this stage. - Steve From coley@linus.mitre.org Sun Feb 24 18:01:40 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA05376 for ; Sun, 24 Feb 2002 18:01:40 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA28599 for ; Sun, 24 Feb 2002 18:01:40 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ON1e821109; Sun, 24 Feb 2002 18:01:40 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ON1ck02177; Sun, 24 Feb 2002 18:01:38 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id SAA02906; Sun, 24 Feb 2002 18:01:38 -0500 (EST) Date: Sun, 24 Feb 2002 18:01:38 -0500 (EST) Message-Id: <200202242301.SAA02906@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: svh@cert.org CC: saag@mit.edu Subject: Re: [saag] INTERNET-DRAFT MITRE Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Shawn V. Hernan" said: >To begin with the section on motivation describes vendor motivation in >terms of their behaviors or attributes [as opposed to motivation.] > >Vendors are motivated in many cases by cost, as is appropriate for a >for-profit organization, enlightened self interest, and good >citizenship.... [examples deleted] The issue with the motivation section probably reflects the fact that I'm not a vendor and so could only guess at some motivations ;-) Thanks for some good examples, hopefully some vendors can chime in here. >what's missing from the motivation section is the implicit assumption >that disclosure in any form is a good thing at all. It is not >intrinsicly obvious that disclosing a vulnerability AT ALL is a Good >Thing. Good point. >I am certain that vendors fix vulnerabilities all the time that never >get disclosed to anyone. Should those vulnerabilities be disclosed >too? I think we should try to stay away from this question, except to say that there may be cases in which a vendor, reporter, and/or coordinator may not want to disclose vulnerabilities. The document covers cases in which one or more parties is going to disclose. The Policy Publication section should be enhanced to say that if an entity sometimes decides not to disclose vulnerabilities, they should say *when* and *why* they won't do so. CERT's disclosure policy does this. >Personally, I believe they should be disclosed because I believe that >individuals and corporations have a right to know what risks they are >facing. But I am unaware of any empirical data to support the argument >for any particular vulnerability. It is rather unfortunate that we are lacking a lot of good empirical data in the area of disclosure. The closest thing we have is the Fither/Arbaugh./etc al. paper, which focused on the relationship of exploits to incidents, as opposed to disclosure practices and opinions. >if there exists a non-zero chance that a malicious person will >discover any *individual* non-disclosed vulnerability, then integrated >over time there is a 100% chance that a malicious individual or group >will find some undisclosed vulnerability. And the consequences of that >discovery could be quite severe. Therefore (and for many other >reasons) , I believe it is in our best collective interests to >responsibly disclose vulnerabilities as the best way to have faith in >the overall security of the network. You are describing what is an unspecified assumption in this document, thanks. >People who do not want to do the right thing won't follow any RFC. >Irrational people are going to act in self-destructive (or random) >ways. And *that* is a community we desperately need to reach. It is also a community that others have to "live with" - whether the people who won't do "the right thing" are reporters, vendors, whatever. The current I-D tries to take this into account, but it contributes to its complexity. >I'd rather avoid issues of arguing over RFC compliance, and instead >spend that time convincing everyone that if the want to do the right >thing, then certain behaviors are empirically found to be beneficial, >and providing people with sets of issues to consider when formulating >their own rational plan for disclosing a vulnerability. I don't think we can make any empirical arguments without good data (hrmmm, I smell a mini-project here). However, a reorganization of this RFC which outlines the *considerations* that people must make during disclosure, and the *impact* of certain choices, may be better than the current checklist of SHOULDs and MUSTs. Now we get away from the thematic issues and into the gory details... >> 2) If the Reporter is unable to notify the Vendor, then the Reporter >> SHOULD ask a Coordinator to notify the Vendor. The Reporter SHOULD >> provide the Coordinator with a list of contacts or mechanisms that were >> used to attempt to notify the Vendor. > >There are additional reasons people may wish to contact a coordinator, >not the least of which is proper scoping, encrypted communications (ever >try to encrypt mail to 100 different vendors before?) third-party >objectivity, etc. I think it is insufficient to involve coordinators >only if the vendor is somehow unresponsive. Agreed, a "new style" I-D or issues paper could give these reasons for how a coordinator could be beneficial. >> 2) The Vendor MUST provide the Reporter and involved Coordinators with >> a Receipt within 7 days. > >I think putting time frames on communications processes will simply lead >to arguments over whether or not someone was "conformant" to the RFC, I think that we can find empirical data that suggests that without feedback from a vendor, a reporter is more likely to publicize an issue. >"After 7 days, I can do whatever I want" does not seem to be >consistent with the spirit of this work. There are recommendations scattered throughout the document that try to cover some of this, but it's not organized that way. >>> 1) If the vulnerability is found in a supported product, the Vendor >>> MUST either (1) reproduce the vulnerability, > >What does it mean to "reproduce" a vulnerability? There seems to be an >implicit assumption that an exploit for the vulnerability exists. The second bullet tries to address this: "determine if there is enough evidence for the existence of the vulnerability when it cannot be reproduced." What constitutes "enough evidence" is an issue that hasn't been discussed. >I would much rather see standards and guidelines that help developers >understand *why* certain constructs are bad, rather than having to >demonstrate time and time again that strcpy is dangerous. We are starting to see this in secure programming books, but I agree that this is a major educational challenge. >An engineer ought to know that some things are just bad. Bullet 1 in section 3.1 (Latent Flaw) tries to cover this: "The Vendor SHOULD ensure that programmers, designers, and testers are knowledgeable about common flaws in the design and implementation of products." But this particular guideline applies across other phases; e.g., when a vendor gets a security vulnerability report, they need to understand why it's a security issue. >no one should assume that the vulnerability is limited to products >from a specific vendor. Agreed. This piece is alluded to for vendors, but it applies to reporters and coordinators, too. It is something that applies across multiple disclosure phases, not just the validation phase for vendors. >> The Vendor SHOULD examine its product to ensure that it is free of >> other problems that are similar to the reported vulnerability. > >Well, this is certainly true, but as a practical matter, does it add >anything to the value of the document? Its certainly not about >disclosure. I think it does, to a certain extent. I've seen a number of cases where somebody discloses a problem and the vendor fixes *only* the problem that was disclosed. One or more reporters then perform followup analyses, then find and report other problems. It is possible that some reporters may intentionally "sit" on multiple bugs in order to report them one at a time to maximize their own public exposure. >Why not include a statement that says "The Vendor MUST NOT introduce >buffer overflows into their products." :-) That's covered by Latent Flaws, section 3.1, bullet 1 :-) >> 6) The Vendor SHOULD provide status updates to the Reporter and any >> involved Coordinators every 7 days. The Vendor MAY negotiate with >> the parties for less frequent updates. > >What if the reporter (or even the coordinator) doesn't want to be >involved beyond the initial report. There is an implicit assumption >throughout the document that the reporters are interested in the >results. Agreed. Maybe this and other bullets should be clarified to say that all parties should be *clear* about their expectations for communications. This "communications breakdown" [1] seems to be the cause of a number of early disclosures - the reporter doesn't get sufficient feedback from the vendor and releases, thinking that the vendor has decided to ignore the issue. Again, we don't have any good empirical data, but since I started thinking about this issue, I've been collecting examples of disclosure issues when I run across them. > 8) The Vendor SHOULD attempt to resolve the vulnerability within 30 > days of initial notification. > >I think 30 days is too short to expect resolution in most cases. 45 >days is pretty tough for many organizations. I think that this is a problem for software engineering in general. I understand why some fixes can take more than 30 days, but this still seems like a good recommendation. In addition, the Vendor Policy explicitly recommends that vendors publicize how long it normally takes them to fix a bug. This in turn will help with future empirical analyses and, possibly, give reporters some valid reasons that might encourage them to delay a report for some time. >> 10) If the Vendor is aware of other vendors that share the same >> codebase as the affected product, then the Vendor MUST either (1) >> notify those vendors, or (2) notify a Coordinator that other Vendors >> may be affected by the reported vulnerability. > >If Vendor A notifies Vendor B about a problem, but vendor B chooses to >ignore it, will Vendor A be willing to rat out Vendor B? At the very least, I would think that Vendor A's responsibilities end after trying to notify other vendors. >I think having a coordinator involved in any multi vendor problem is >valuable. Yes, this should be specified in the document. >> 1) The Reporter SHOULD work with the Vendor in a timely fashion to >> explain the vulnerability and conduct further analysis. > >Why? Isn't that why people pay for software in teh first place, so that >vendors will fix the problems? As a consumer of commercial software, it >seems onerous to have to do testing in addition to paying for the >software and an expensive maintenance contract. Now granted, most people >would be willing to work with their vendors, but this seems to imply >that they ought to. OK, perhaps a different way of putting this is to give a rationale for why a reporter should consider doing this: the problem may be due to an unusual environmental condition or configuration; it could save the vendor time in identifying the source of the problem, thus leading to a faster resolution; etc. >> 2) If the Vendor does not understand the nature, risk, or resolution >> of the vulnerability, then the Reporter or involved Coordinators >> SHOULD provide the Vendor with resources that help to explain the >> vulnerability. > >This too seems to let the vendors off the hook a bit. Again, many people >would say that this is what maintenance agreements are for. Reporters sometimes find a problem, and the Vendor *wants* to fix it, but they don't understand the nature of the issue. Some reporters may go out of their way to explain the problem to the vendor. I once spent over 20 hours with a willing vendor who didn't understand the problem. Obviously that sort of dedication shouldn't be required, and maybe it shouldn't even be a "should." But it would be nice to highlight this as "particularly good behavior." Perhaps the use of the term "resources" is too vague here. I was thinking along the lines of the reporter suggesting "go to this URL, or buy these books, to understand why .. sequences in pathnames can be bad." >> 5) The Reporter SHOULD grant time extensions to the Vendor if there >> is evidence that the Vendor is acting in good faith to resolve the >> vulnerability. > >Time extensions to what? Good point. Time extensions for the vendor to apply a resolution, beyond the suggested 30 days after initial notification. >> 1) The Coordinator MUST attempt to resolve any conflicts or technical >> disagreements that arise between the Reporter and the Vendor. > >Too broad. Coordinators have no responsibility to resolve "any" >conflicts. Conflicts often center around issues like supported software, >access to source code, licensing issues, access to beta software, direct >access to engineers, etc, etc. ad naseum. I'll weaken to a MAY. Perhaps in the rewrite, the role of coordinators should be in a separate section altogether. >> 1) The Vendor MUST identify the fundamental nature of the flaw within >> the source code or in the design of the product ("Diagnosis"). > >Why? From many vendors' perspective, the less said about the cause of >the problem, the better. I believe there is value to the research and >educational community in knowing about the nature and frequency of the >cause of vulnerabilities, but many organizations (customers in this >case) would PREFER that their vendors be quiet about the cause of the >problem. Here we get into the issue of what "Jane Q. Customer" wants versus the "Security Community." Perhaps this could be rephrased to say, "if the Vendor wants to provide 'the security community' with information that helps them, then the vendor SHOULD identify the fundamental nature of the flaw..." With a phrasing such as that, then Vendors who want to address the needs of a certain segment of the community can do so; others may decide not to, but have a better understanding of how the impact of their decisions. >> 5) After the Grace Period, the Reporter MAY release additional >> details. The Reporter SHOULD carefully consider how much detail is >> needed by Customers and the Security Community. > >When is the first release of information? In Section 3.7, the recommendation is that all parties agree on a release date. Perhaps the whole issue of timing should be dealt with in a separate section, instead of being "integrated" as it currently is. >[other specific points removed for "brevity"] >> 5) If a Coordinator has properly followed the process, then the >> Vendor SHOULD provide credit to the Coordinator. > >Why the weaker standard for coordinators? Hrmmm... I'm not sure why. Coordinators don't seem to be credited as often as reporters currently, so maybe the weaker standard was intended to reflect current practices. >> 6) If a Reporter has not properly followed the process and publicly >> announces the vulnerability, then the Vendor MAY provide credit to >> the reporter. >This seems to imply that the vendor may choose not to credit someone if >they don't follow the process, and that smacks to me of plagiarism. >If a reporter chooses to assert his or her intellectual property >rights, then I cannot support a BCP that allows vendors to ignore >those rights. Indeed, I don't think the Provost of CMU would let >me. A vendor may choose to label a person or group as irresponsible, >stupid, or outright malicious, but should not be able to violate basic >academic integrity standards by hiding behind a BCP. The "credit" is >not the vendor's to withhold. I suspect that this will be a controversial issue. I don't recall any public debates about this particular question. As you know, some vendors have specific policies in which they do not provide credits to someone who does not follow "proper protocol" (whatever that is, which is what this I-D is trying to do). Many people probably think that "MAY" is probably too weak, but there has been little or no public discussion on this particular point, so it's hard to suggest what "best practices" are. >> 8) The Vendor SHOULD cryptographically sign all patches using a >> method that is commonly accessible on the platforms for the Vendor's >> product. The Vendor should clearly advertise its cryptographic key >> and provide cryptographic checksums for its patches. > >In general, I think any BCP in this arena ought to talk more extensively >about the use of secure communication channels, particularly between >coordinators and vendors. If you don't want a vulnerability disclosed, >you shouldn't send it in plain text email. Good point. More crypto. >But what about when two trustworthy parties disagree? See for example >http://www.cert.org/advisories/CA-2000-12.html This subtlety isn't really captured in this document, though after a particular time frame, one or more of the disagreeing parties can release. Perhaps there should be a recommendation that parties should at least try to agree on a release date, or the one who will release should give some amount of warning. >> 2) The Vendor SHOULD NOT re-release the same advisory for newly >> discovered, closely related vulnerabilities. > >If new action needs to be taken what choice do they have? I'm missing >the point of this. It can make vulnerabilities difficult to track. Perhaps I see this more often than others because CVE is "in the middle" of these things, but I've run across a number of re-releases of advisories that announce new vulnerabilities, but the issues are missed by the customers - or, worse, by the vulnerability information sources that customers may use, including CVE. The rationale for this bullet also makes the point, I think: Rationale: The re-release of an advisory may not be noticed as well by Customers, which could cause the Customers to believe that their systems are secure because they applied the resolution that was identified in the original advisory. >Again, I applaud the effort, and I hope these comments are taken in >the spirit in which they're intended. They are, thanks! - Steve [1] Led Zeppelin. From coley@linus.mitre.org Sun Feb 24 18:06:42 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA05460 for ; Sun, 24 Feb 2002 18:06:42 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA23133 for ; Sun, 24 Feb 2002 18:06:42 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ON6f821322; Sun, 24 Feb 2002 18:06:41 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ON6ek02486; Sun, 24 Feb 2002 18:06:40 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id SAA03083; Sun, 24 Feb 2002 18:06:39 -0500 (EST) Date: Sun, 24 Feb 2002 18:06:39 -0500 (EST) Message-Id: <200202242306.SAA03083@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: tim@fungible.com CC: saag@mit.edu Subject: [saag] Re: Vulnerability Disclosure: When does grace period start; comments Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Tim Fungible said: > The Vendor MAY ask the Reporter and Coordinator to allow a "Grace > Period" up to 30 days, during which the Reporter and Coordinator do > not release details of the vulnerability that could make it easier > for hackers to create exploit programs. > > There is no indication of when the grace period starts. It might > start at the time of initial notification, or it might start at the > time the vendor has resolved the vulnerability. Good question. The Grace Period needs to be defined. It starts after Release... customers may be given a certain grace period before full details of the vulnerability are disclosed. Come to think of it, this grace period is *not* just something that some vendors have asked for. Some reporters already define their own grace periods. They may announce a vulnerability and say "I'm not releasing details yet, in order to give admins a chance to patch their machines." Or, they may wait a few weeks until after the vulnerability was announced to customers, then say "OK, I'm the person who discovered this problems. Sysadmins should have patched by now, so here are the details." >2. The document does not include any email addresses that can be used > for discussing its contents or contacting the authors. It's buried in page 27. Regards, - Steve From coley@linus.mitre.org Sun Feb 24 18:15:42 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA05575 for ; Sun, 24 Feb 2002 18:15:42 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA25032 for ; Sun, 24 Feb 2002 18:15:41 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ONFf821876; Sun, 24 Feb 2002 18:15:41 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ONFek03500; Sun, 24 Feb 2002 18:15:40 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id SAA03206; Sun, 24 Feb 2002 18:15:39 -0500 (EST) Date: Sun, 24 Feb 2002 18:15:39 -0500 (EST) Message-Id: <200202242315.SAA03206@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: eddiealz@eudoramail.com CC: saag@mit.edu Subject: [saag] Re: Responsible Disclosure finally an Internet-Draft Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Edward Alz" said: >It's useful if the vendor sets appropriate expectations about whether >a network application is suited to high-risk network environments. >It's useful if the vendor comments on how security was considered in >the design. It's even more useful if the vendor outlines what >approach they used to avoid common implementation flaws. Except in >clear cases where essentially *any* use of the program will see >untrusted input from the outside world (e.g. mail agents), there can >be huge value in having software available at all, even if the Vendor >is unconcerned with security. > >Take an open-source application that provides, say, a "better" (in >some way) database. If it says in big letters "Here's a database >that you can run standalone, and I answer support e-mails. But >it'll also read data over the network. The code that reads it >might be wrong. I didn't audit it. No one else audited it. If >you need to use this on a network, SPEND YOUR OWN MONEY and get the >network code audited and fixed." this should be 100% ok. Good point. Perhaps this should be an additional item in the Vendor Policy: what expectations the Vendor's users should have for the security of the software, plus what efforts the Vendor will make to resolve any issues. >To summarize: "end user says the magic word 'vulnerability'" should >not always imply "vendor must spend time/money to satisfy user". Agreed. >Similarly, "vendor says the magic phrase 'I don't understand the >vulnerability'" should not imply "reporter should become an unpaid >member of vendor's QA team". Agreed; Shawn Hernan basically made the same point. >I'd be happier with "if Vendor does not gain clue within amount of >time Reporter can afford, then Reporter should disclose and ask >General Public (or Coordinator) to help give clue to Vendor". Good point. This could also apply if the vendor explicitly states that they won't fix a problem. Sometimes a reporter will include a vendor statement when the vendor won't produce a resolution. It might be good to reflect this practice in the document. Thanks, - Steve From coley@linus.mitre.org Sun Feb 24 18:34:38 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA05864 for ; Sun, 24 Feb 2002 18:34:37 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA27628 for ; Sun, 24 Feb 2002 18:34:37 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ONYa822938; Sun, 24 Feb 2002 18:34:37 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ONYZk04890; Sun, 24 Feb 2002 18:34:35 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id SAA03474; Sun, 24 Feb 2002 18:34:25 -0500 (EST) Date: Sun, 24 Feb 2002 18:34:25 -0500 (EST) Message-Id: <200202242334.SAA03474@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: DEndler@idefense.com CC: saag@mit.edu Subject: Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: David Endler said various things in which he agreed with some previous poster. In addition to those things, he said: >I would love to see a companion document with even more details on the >software development lifecycle responsbilities of vendors responding >to security vulnerabilities (i.e. timeliness of response team, QA team >testing, regression testing of patches, etc.). Interesting suggestion, perhaps someone else can do this one ;-) >[There should be] Some form of dispute resolution process (everything >so far assumes cooperation and love abound between reporters and >vendors, not sure who would mediate)... [as well as] Contingencies for >the reporter at each stage if the vendor refuses or fails to abide by >their assumed responsibilities (assuming no dispute process occurs) Coordinators are mentioned as a means for resolving disputes, but since disputes could happen in many different phases, perhaps the current document could be modified to make this clearer, as well as providing suggestions other dispute scenarios (e.g., Reporter says "I've given you 45 days already, I'm going to release" and Vendor says "We just need 5 more days.") >The identity of the Corrdinator is rather vague, perhaps purposely so? >I assume this can be a recognized security figure, another vendor, my >dog, etc.? I didn't want to "name names" but there are obvious coordinators today such as CERT/CC, Russ Cooper, SecurityFocus VulnHelp, etc. But there may be others who play this role, *or* new types of Coordinators may arise. Consider the Sardonix project, which may wind up becoming a coordinator of sorts. >I assume that there is an implied NDA between the Coordinator and the >Reporter? This should be explicitly stated, unless it's deemed ok for >the Coordinator to forward it on to 3 more Coordinators, and they'll >forward it to 5 of their Coordinator friends, etc. Agreed that there should be explicit understandings for how information is to be shared, and with whom. >Some vendors may not even exist anymore, what then? Should the >disclosure process include going to a Meta-Vendor or Coordinator, >someone who can develop a patch just as easily but may not be directly >associated with the product? Good question. The general approach *appears* to be to release the vulnerability, at least what I see on Bugtraq. >>1) Latent Flaw. A flaw is introduced into a product during its >> design, specification, development, installation, or default >> configuration. > >Flaws can also be introduced by integrating one or more technologies >together improperly, where neither of them independently may involve a >vulnerability. Great point. >> 4) If a Reporter has properly followed the process, then the Vendor >> MUST provide credit to that reporter. >> >> 5) If a Coordinator has properly followed the process, then the >> Vendor SHOULD provide credit to the Coordinator. > >I would say credit should be given as the Reporter/Coordinator wishes. R/C >may wish to remain anonymous, be associated with their company, NOT be >associated with their company, etc. There are other issues with credit that have been raised, but assigning credit based on the reporter/coordinator's wishes does seem like a reasonable thing to do. >Just a few early comments, I'm sure I'll have more :-) Ummmm... there's no big rush ;-) (just kidding, it was a joke about the volume of responses we've received so far) Regards, - Steve From coley@linus.mitre.org Sun Feb 24 18:40:00 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA05936 for ; Sun, 24 Feb 2002 18:39:59 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA28548 for ; Sun, 24 Feb 2002 18:39:59 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ONdx823143; Sun, 24 Feb 2002 18:39:59 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1ONdwk05325; Sun, 24 Feb 2002 18:39:58 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id SAA07969; Sun, 24 Feb 2002 18:39:47 -0500 (EST) Date: Sun, 24 Feb 2002 18:39:47 -0500 (EST) Message-Id: <200202242339.SAA07969@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: phoffman@imc.org CC: saag@mit.edu Subject: [saag] Re: Internet-Draft for "Responsible Disclosure Process" released Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Paul Hoffman / IMC said: >To echo what a few other people have said: why is this document so >long? It sounds more like a white paper than short, crisp definition >of Best Current Practices. Yes, it's starting to appear that a shorter BCP with a "companion" white paper may be the best approach. But as the extensive comments illustrate, if the short BCP is too "loose," then it may leave too much room for abuse by particular parties. Even the current comprehensive document has a number of loopholes that people have discovered. - Steve From coley@linus.mitre.org Sun Feb 24 19:07:54 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA06278 for ; Sun, 24 Feb 2002 19:07:54 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA10252 for ; Sun, 24 Feb 2002 19:07:54 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1P07r824397; Sun, 24 Feb 2002 19:07:53 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1P07pk07258; Sun, 24 Feb 2002 19:07:51 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id TAA08412; Sun, 24 Feb 2002 19:07:51 -0500 (EST) Date: Sun, 24 Feb 2002 19:07:51 -0500 (EST) Message-Id: <200202250007.TAA08412@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: shalunov@internet2.edu CC: saag@mit.edu Subject: Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: stanislav shalunov said: [various things that others have said, deleted for "brevity"] >> If vendors had knowledgeable programmers/etc., then there wouldn't >> be as much vulnerability reporting. > >But what does it have with practices of reporting security >vulnerabilities? This (and similar) advice seems to be out-of-place. > >> If you'd like a more specific answer: sometimes vendors do not even >> understand a vulnerability report. > >And how would writing a document about disclosure protocol help? > >> We decided to highlight "Security Community" because they are a >> special class of consumers of vulnerability information. > >But you require something of a class of people as a whole. Does >person X (who might or might not consider himself part of the >"Security Community") need to fulfill these requirements each and >every time there's a security-sensitive bug reported? Surely not... These might be better addressed in the aforementioned "white paper." >aYou haven't asnwer my question about how much time you expect to pass >before an exploit for a problem is posted after it is first reported >to a vendor that does nothing to fix it. This is one of the difficulties for how the current timing is laid out. I agree that it's not particularly clear. >My calculation seems to >indicate that it is: > 7 days before auto-response >10 days before clerical "looking into it" This is really only 3 days after the 7 days for auto-response. >30 days before "not done yet", with weekly "looking" The intention is 30 days after initial notification. Then there may be "time extensions" as requested by the vendor, and agreed to by the reporter. These will vary. >30 days of grace period Before the grace period starts, there is an announcement that "*some* vulnerability has been discovered." After the grace period (possibly up to 30 days), the additional details may be released. The grace period needs to be more explicitly "spelled out" in the document. >77 days before one can post an exploit in a case of a deadbeat >vendor? I guess it depends on how the vendor is being a deadbeat: - if the vendor is completely unresponsive or inaccessible, then it's either 7 days or 10 days - if the vendor says "we're looking into it" but then starts to ignore the reporter, then it's (maybe) 30 days - if the vendor asks for time extensions and appears to be acting in good faith, but then the reporter starts thinking that the vendor has *stopped* acting in good faith, then it's X days (where "X" is the day that the reporter decided the vendor wasn't acting in good faith) - if the vendor is a deadbeat, then the reporter might decide to ignore the grace period entirely. The reporter controls much of the timing of this process. 77 days could happen, but only if a vendor really strings a reporter along, or if the reporter disagrees with how the vendor is handling the issue. One thing that's missing from this document is a "last chance" notice for the reporter to tell the Vendor when they plan to release, even if the Vendor isn't ready. This seems to be effective in some cases and, if done more frequently, might reduce the number of issues that are released without a resolution. Your questions really highlight the need to specifically identify the suggested timeline in a separate section. >what about situations when the reporter had repeatedly bad experience >with a particular vendor and has grounds to assume that the vendor is >not acting in good faith when requesting delays and similar >situations? That's a good question. The vendor could be given a small chance (just in case they change their ways), but this could be difficult to formalize. >"Coordinators" have rather rigid roles and quite vague definition. Coordinators are a piece of the puzzle, but past discussions have been focused almost exclusively on the reporter/vendor relationship. As a result, the coordinator portions of the document are less mature. - Steve From coley@linus.mitre.org Sun Feb 24 19:15:27 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA06401 for ; Sun, 24 Feb 2002 19:15:27 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA04324 for ; Sun, 24 Feb 2002 19:15:26 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1P0FQ824748; Sun, 24 Feb 2002 19:15:26 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1P0FOk07849; Sun, 24 Feb 2002 19:15:24 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id TAA08506; Sun, 24 Feb 2002 19:15:14 -0500 (EST) Date: Sun, 24 Feb 2002 19:15:14 -0500 (EST) Message-Id: <200202250015.TAA08506@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: Ken@infosec101.org CC: saag@mit.edu Subject: RE: [saag] draft-christey-wysopal-vuln-disclosure-00.txt Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Ken Pfeil" said: >One thing that I see noticably missing in this entire process is the >"workaround" issue... Granted, it may not always be possible to >completely eliminate a bug from the codebase within 30 days, but >surely the vendor can recommend a suitable workaround (configuration >or otherwise) within a shorter timeframe that will help minimize the >associated risks. Outside of disabling a service entirely, sometimes there is no workaround. And if the service is essential (say, a mail or DNS server), then disabling it may not be a good option. >Notice that I categorized discoverer and reporter separately. We focused on the reporter because it clearly identifies the person who actually interfaces with the vendor and others. The discoverer may play no role whatsoever in the disclosure. >I consider 7 days for a vendor to acknowledge someone's existence, and >that they ever received an email to be quite generous. This is straight from RFPolicy. 7 days normally accounts for (1) small vendors, (2) vacations, and (3) differences in work weeks across the globe. (Not everybody works Monday-Friday). >If companies took 7 days to respond to a customer, that customer would >probably take their business elswhere. We don't have good empirical data for how long it takes companies to respond. But the terminology of this I-D could help make it easier for doing empirical analysis, and for communicating to customers how long it takes a vendor to respond to something. Thanks, - Steve From coley@linus.mitre.org Sun Feb 24 20:30:41 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA07126 for ; Sun, 24 Feb 2002 20:30:41 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA15908 for ; Sun, 24 Feb 2002 20:30:40 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1P1Ue828205; Sun, 24 Feb 2002 20:30:40 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1P1Udk12288; Sun, 24 Feb 2002 20:30:39 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id UAA13773; Sun, 24 Feb 2002 20:30:38 -0500 (EST) Date: Sun, 24 Feb 2002 20:30:38 -0500 (EST) Message-Id: <200202250130.UAA13773@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: eddiealz@eudoramail.com CC: saag@mit.edu Subject: [saag] Re: Internet-Draft for "Responsible Disclosure Process" released Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Edward Alz" said: >If a BCP is needed, I suggest that it instead describe how >Vendors can provide better information to Reporters, so >Reporters can carry out their "important role in enhancing >Internet security" more effectively. Specifically: what type >of reports will the vendor act on, how long will it take, and >what else should the Reporter expect. Put the information at >www.vendor_site.com/vulnerability_handling. Relative to the current I-D, it sounds like you're suggesting that we expand the "Vendor Policy" section (4.1). With your examples: > * software should only be used within a well-isolated, > well-monitored intranet (except for tcp ports open to web > and mail servers) This would be outside the scope of a disclosure I-D. > * wants reports about any type of vulnerability Not currently mentioned in the doc, good point. > * all reports get an initial reply within 5 days; reporter > can provide information about application failure, > crashes, etc. but if exploitability is unknown, completion > of a fix may take much longer This would be a statement of the time for "Vendor Receipt" (section 3.4). > * average fix time for remote access: 3 months > * average fix time for remote DoS: 9 months A description of how they prioritize their problems and their expected response times. More specific than section 4.1 #2. > * prior to public fix, vendor will provide a fix to: 100 > largest customers, U.S. and many other governments, ISACs Good point, should have a name for it... "release process" or "release policy" perhaps. >Neither of these two is necessarily better. A slight modification: people will have different opinions as to which is better :-) But it more clearly puts the choice in the hands of customers and others, "truth in advertising" as it were, and it makes it easier for everyone to compare and contrast the different approaches. Regards, - Steve From shalunov@internet2.edu Sun Feb 24 20:36:25 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA07224 for ; Sun, 24 Feb 2002 20:36:25 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA17069 for ; Sun, 24 Feb 2002 20:36:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 692E35EE00; Sun, 24 Feb 2002 20:36:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 76C725EDF3; Sun, 24 Feb 2002 20:36:10 -0500 (EST) To: "Steven M. Christey" Cc: saag@mit.edu Subject: Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt References: <200202250007.TAA08412@linus.mitre.org> From: stanislav shalunov Date: 24 Feb 2002 20:36:50 -0500 In-Reply-To: <200202250007.TAA08412@linus.mitre.org> Message-ID: <87bsee8hql.fsf@cain.internet2.edu> Lines: 51 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Steven M. Christey" writes: > This is really only 3 days after the 7 days for auto-response. Ah, that's better (and should be clarified). > The intention is 30 days after initial notification. Ditto. > I guess it depends on how the vendor is being a deadbeat: > [up to 30 days unless the reporter agrees extensions] 30 days is much more reasonable than my interpretation of 77 days. I'm not sure that 30 days is the generally agreed-on number, but the reasonable range is probably somewhere around 14-30 days. > One thing that's missing from this document is a "last chance" notice > for the reporter to tell the Vendor when they plan to release, even if > the Vendor isn't ready. The reporter probably should be encouraged to mention his plans for public release right from the very beginning. The release can later be delayed if the reporter (or coordinator, whichever is applicable) agrees. > >what about situations when the reporter had repeatedly bad experience > >with a particular vendor and has grounds to assume that the vendor is > >not acting in good faith when requesting delays and similar > >situations? > > That's a good question. The vendor could be given a small chance > (just in case they change their ways), but this could be difficult to > formalize. Do I take it that you agree that the document should state that in cases when the reporter (or the coordinator) has evidence of active malicious exploitation of a bug in the wild, the full details should be disclosed immediately? Further, what about those preliminary announcements of vulnerabilities that are considered to not include enough detail to construct a working exploit (but contain enough detail for a work-around in many cases, such as disabling a given non-critical service temporarily)? Should they be delayed a month as well, according to your point of view? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at sea level. From Ken@infosec101.org Sun Feb 24 21:43:42 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA07913 for ; Sun, 24 Feb 2002 21:43:42 -0500 (EST) Received: from mail1.intermedia.net (mail1.intermedia.net [206.40.48.151]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA27921 for ; Sun, 24 Feb 2002 21:43:41 -0500 (EST) Received: from arrow1 (unverified [66.67.44.45]) by mail1.intermedia.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Sun, 24 Feb 2002 18:43:40 -0800 Reply-To: From: "Ken Pfeil" To: "Steven M. Christey" Cc: Subject: RE: [saag] draft-christey-wysopal-vuln-disclosure-00.txt Date: Sun, 24 Feb 2002 21:42:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200202250015.TAA08506@linus.mitre.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steve, Great job in keeping up with all the posts, BTW. Hope carpal tunnel doesn't sink in :-) SMC> Outside of disabling a service entirely, sometimes there is no > workaround. And if the service is essential (say, a mail or DNS > server), then disabling it may not be a good option. The are often much simpler workarounds, such as disallowing access from untrusted hosts, removing extensions (hehe, .ida and .idq come to mind right off), etc. Not to beat a dead horse, but my concern is that the public will be put at risk for much longer periods of time than is necessary while the vendor puts it on the backburner using RFCsuch-and-such as leverage. > KMP> >Notice that I categorized discoverer and reporter separately. SMC> We focused on the reporter because it clearly identifies the person > who actually interfaces with the vendor and others. The discoverer > may play no role whatsoever in the disclosure. I thought the "coordinator" interfaces with the vendor? Out of curiosity, how does this place into multiple reporting scenarios? Are all reporting mechanisms/vehicles treating with the same regard? Another thing I was wondering: How should vulns be treated from a "dead company" product that gets widely deployed? Or a widely deployed product that is no longer supported by the vendor? Am I forced to "upgrade" just to be as secure as I should have been in the first place? Or will there be a recommendation for a codebase escrow (for closed source products, I can't envision the same scenario with an open code base)? By "dead company", I mean companies that have closed their doors for good, or even taken over by another. Best Regards, Ken From cwysopal@atstake.com Sun Feb 24 22:21:46 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA08297 for ; Sun, 24 Feb 2002 22:21:46 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id WAA11871 for ; Sun, 24 Feb 2002 22:21:46 -0500 (EST) Received: (qmail 26358 invoked from network); 25 Feb 2002 03:24:36 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 25 Feb 2002 03:24:36 -0000 Received: from atstake.com (ssh-gw.atstake.com [63.168.6.76]) by cam-relay.atstake.com (Postfix) with SMTP id D48A922817; Sun, 24 Feb 2002 22:20:35 -0500 (EST) Message-ID: <3C79ADC5.7070603@atstake.com> Date: Sun, 24 Feb 2002 19:21:41 -0800 From: Chris Wysopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: stanislav shalunov Cc: "Steven M. Christey" , saag@mit.edu Subject: Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt References: <200202250007.TAA08412@linus.mitre.org> <87bsee8hql.fsf@cain.internet2.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: stanislav shalunov wrote: > 30 days is much more reasonable than my interpretation of 77 days. > I'm not sure that 30 days is the generally agreed-on number, but the > reasonable range is probably somewhere around 14-30 days. 30 days was a target that we were shooting for. Most vendors for most problems seem to be able to get close to this deadline. Yet there will always be vulnerabilities that are deep design problems or vulnerabilities that effect dozens of supported versions of a product. For design problems there will always be a larger coding effort and a larger regression testing effort. When there are many supported versions, even if the code fix is small there is the sheer mechanics of creating dozens of patches, regression testing them, and packaging them up. A suggestion I have seen is for vendors that have problems getting patches out within the 30 day timeframe post a "service level agreement" explaining to their customers what to expect. Codifying this into this I-D is just going to make the document more complex. > > Do I take it that you agree that the document should state that in > cases when the reporter (or the coordinator) has evidence of active > malicious exploitation of a bug in the wild, the full details should > be disclosed immediately? This has been a suggestion from both reporters and vendors. Reporters or vendors would give out as much details as attackers are known to have and any known workarounds in lieu of a patch. But how does the evidence get delivered? Reporters or vendors would need to monitor incident organizations or incident lists. Not everyone is going to be able to do this. > Further, what about those preliminary announcements of vulnerabilities > that are considered to not include enough detail to construct a > working exploit (but contain enough detail for a work-around in many > cases, such as disabling a given non-critical service temporarily)? It would be best to not give out the details to create an exploit but often times the exploit is circulating widely anyway. We tried to stay away from report content and level of details in this I-D and just stick to process because defining would make the document even larger and more complex. > Should they be delayed a month as well, according to your point of view? The delay for a grace period would have to take into account active exploit in the wild. The grace period would be pre-empted also. Chris Wysopal From shalunov@internet2.edu Sun Feb 24 23:24:06 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA08927 for ; Sun, 24 Feb 2002 23:24:06 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA21721 for ; Sun, 24 Feb 2002 23:24:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id B746A5EE00; Sun, 24 Feb 2002 23:23:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id B73AC5EDF3; Sun, 24 Feb 2002 23:23:51 -0500 (EST) To: Chris Wysopal Cc: "Steven M. Christey" , saag@mit.edu Subject: Re: [saag] draft-christey-wysopal-vuln-disclosure-00.txt References: <200202250007.TAA08412@linus.mitre.org> <87bsee8hql.fsf@cain.internet2.edu> <3C79ADC5.7070603@atstake.com> From: stanislav shalunov Date: 24 Feb 2002 23:24:31 -0500 In-Reply-To: <3C79ADC5.7070603@atstake.com> Message-ID: <87y9hi5gu8.fsf@cain.internet2.edu> Lines: 45 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Chris Wysopal writes: > stanislav shalunov wrote: > > Do I take it that you agree that the document should state that in > > cases when the reporter (or the coordinator) has evidence of active > > malicious exploitation of a bug in the wild, the full details should > > be disclosed immediately? > > This has been a suggestion from both reporters and vendors. Reporters > or vendors would give out as much details as attackers are known to have > and any known workarounds in lieu of a patch. But how does the evidence > get delivered? Reporters or vendors would need to monitor incident > organizations or incident lists. Not everyone is going to be able to do > this. If the reporter (or coordinator, as appropriate) does not have evidence of exploits circulating in the wild, he should assume it is not circulating. (My double-quoted formulation above captures that.) No assumptions are made about the level of knowledge of things in the wild by the reporter. > > Further, what about those preliminary announcements of vulnerabilities > > that are considered to not include enough detail to construct a > > working exploit (but contain enough detail for a work-around in many > > cases, such as disabling a given non-critical service temporarily)? > > It would be best to not give out the details to create an exploit but > often times the exploit is circulating widely anyway. We tried to stay > away from report content and level of details in this I-D and just stick > to process because defining would make the document even larger and more > complex. Certain kinds of vulnerability reports are probably best left exempt from any recommended delays. The content-based criterion above is an example of a class of such reports. Another class of reports are those that contain only information already known to the black hats. There might be other similar classes. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ A large number of installed systems work by fiat. That is, they work by being declared to work. -- Anatol Holt From tytso@MIT.EDU Mon Feb 25 00:25:16 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id AAA09687 for ; Mon, 25 Feb 2002 00:25:16 -0500 (EST) From: tytso@MIT.EDU Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA03045; Mon, 25 Feb 2002 00:25:15 -0500 (EST) Received: from ted-w20.mit.edu ([18.187.1.124] helo=think.thunk.org) by thunk.org with asmtp (Exim 3.34 #1 (Debian)) id 16fDdT-0003mj-00; Mon, 25 Feb 2002 00:25:15 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16fDdS-00019o-00; Mon, 25 Feb 2002 00:25:14 -0500 To: saag@mit.edu Phone: (781) 391-3464 Message-Id: Date: Mon, 25 Feb 2002 00:25:14 -0500 Subject: [saag] The Responsible Disclosure draft: A Bad Idea Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I'm going to take a very different tack on this document, which is that I think it's a very bad idea, and shouldn't be published by the IETF at all. The IETF is an organization which whose primary strength is writing protocols for the purposes of ensuring interoperability, not policy documents, and writing a policy document in the style of a protocol, by using RFC-2119 MUST/SHOULD language doesn't change the fact that it isn't a protocol. Why is do I believe it is a bad idea for the IETF to publish a policy document? First of all, it's not at all clear to me that it is a good thing to standardize a single process for dealing with security bugs (interoperability not being a major issue here), and in fact, I can think of several bad reasons for this. Secondly, it closes a debate for which there is no consensus in the community --- namely whether full, semi-full, or complete-closed disclosure is the Right Answer. Even if someone participates primarily in the semi-closed disclosure community, the fact that there are a number of people who practice FULL disclosure is extremelly useful, because it acts as a sanity check on those who practice semi-closed and closed disclosure. In any process, it's always possible for a vendor to abuse the process, by stretching out the disclosure periods as much as possible. Even worse, historically, it seems that since the "coordinator" primarily gets their revenue from the vendors, they generally tend to side in favor of the vendor and don't necessarily act in the interests of the users and system administration community (i.e., the Enron factor). Indeed, I've seen cases (as recently as in the past month) where a coordinator arguably abused its discretion by suppressing knowledge of a security bug for what seemed to be inappropriately long periods --- in fact, to the point where it became demonstrably clear that the announcement should have been sent much, much earlier. Hence, having people who are practicing FULL disclosure is very useful thing, in that if the process gets abused, or the coordinator gets captured by the vendors and attempts to try to keep something secret for too long, there's a natural, and LEGAL way for the knowledge to be disseminated outside of the semi-closed process. The problem with the IETF publishing a document, with the full imprimatur of RFC status, is that it may reprecussions in the real world that may not be desireable. At the minimum, it may cause people who disclosure full disclosure to be subject to lawsuits based on the fact that they had violated this particular RFC, and had therefore acted "irresponsibility". It would be absolutely disastrous if some number of federal or state legislatures used this document as model legislation which prohibited any other form of disclosure but what has been described in this document as "responsible". So imagine if you will a world where a vendor and coordinator act in bad faith --- it would be really, really, bad if the person who finds the security bug finds themselves forbidden from bypassing the vendor and coordinator due to laws or threats of lawsuits which were facilitated by the publication of this document with the IETF blessing. As a result, I don't believe the IETF should publish this document, regardless of how it might be tweaked. While it may be useful to have a document which describes a process for doing semi-closed reporting, the possibility that it might be used by companies (such as Microsoft, reportedly) who have been lobbying governments to outlaw full disclosure is so horrible that it outweighs, in my opinions, any positive value which publishing this document might have. Personally speaking, I primarily participate in what this document calls "responsible disclosure", but I want that to be my choice, not something where the IETF, and maybe later on the U.S. Government, tells me that it's something that I MUST do. There will always be special cases which any process document cannot cover, and so I want the escape hatch to be always a possibility. I suppose we could fix this by adding the following disclaimer at the beginning of the document: "At any point in time, the reporter MAY choose to make the vulnerability public, for any reason, and via any forum at the reporter's discretion, and this will also be considered 'responsble reporting'." With this kind of "First Amendment" guarantee in the document, it might be acceptable to have the IETF publish such a document. But somehow I doubt the authors would be willing to put such an exception in their document..... At the very least the SAAG and the authors should very carefully consider the MUST's and SHOULD's, and meditate on whether or not they would mind being thrown jail for five years, or sued for ten million dollars, if they happened to violate any of the MUST's or SHOULD's in the document. If you're not comfortable with that, then maybe it should be dropped from the document --- and maybe the document should be dropped entirely. - Ted From cwysopal@atstake.com Mon Feb 25 01:48:17 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id BAA10594 for ; Mon, 25 Feb 2002 01:48:17 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id BAA07463 for ; Mon, 25 Feb 2002 01:48:17 -0500 (EST) Received: (qmail 26981 invoked from network); 25 Feb 2002 06:51:06 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 25 Feb 2002 06:51:06 -0000 Received: from atstake.com (ssh-gw.atstake.com [63.168.6.76]) by cam-relay.atstake.com (Postfix) with SMTP id 1AA9922817; Mon, 25 Feb 2002 01:48:07 -0500 (EST) Message-ID: <3C79DE64.4000403@atstake.com> Date: Sun, 24 Feb 2002 22:49:09 -0800 From: Chris Wysopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: tytso@mit.edu Cc: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: tytso@MIT.EDU wrote: > The IETF is an organization which whose primary strength is writing > protocols for the purposes of ensuring interoperability, not policy > documents, and writing a policy document in the style of a protocol, by > using RFC-2119 MUST/SHOULD language doesn't change the fact that it > isn't a protocol. The document could be rewritten to not use the RFC-2119 MUST/SHOULD language but precision is better than vagueness even in a BCP. > Why is do I believe it is a bad idea for the IETF to publish a policy > document? First of all, it's not at all clear to me that it is a good > thing to standardize a single process for dealing with security bugs > (interoperability not being a major issue here), and in fact, I can > think of several bad reasons for this. Can we just call it a Best Current Practice document and not a policy document? There certainly is a range of dealing with security bugs and not one single process. Perhaps the document needs to be more flexible to encompass a wider range. > Secondly, it closes a debate for which there is no consensus in the > community --- namely whether full, semi-full, or complete-closed > disclosure is the Right Answer. Even if someone participates primarily > in the semi-closed disclosure community, the fact that there are a number > of people who practice FULL disclosure is extremelly useful, because it > acts as a sanity check on those who practice semi-closed and closed > disclosure. I look at the full disclosure argument as more of a content issue than a process issue. The process in this document doesn't even recommend that a reporter not publish malicious worm code at vendor patch release time. It does specify that reporters should work with vendors to get the problem resolved before releasing information. This is a practice that is followed greater than 95% of the time currently. > In any process, it's always possible for a vendor to abuse the process, > by stretching out the disclosure periods as much as possible. Even > worse, historically, it seems that since the "coordinator" primarily > gets their revenue from the vendors, they generally tend to side in > favor of the vendor and don't necessarily act in the interests of the > users and system administration community (i.e., the Enron factor). Most coordinators are fairly independant but that is certainly an issue that should be guarded against if possible. > Indeed, I've seen cases (as recently as in the past month) where a > coordinator arguably abused its discretion by suppressing knowledge of a > security bug for what seemed to be inappropriately long periods --- in > fact, to the point where it became demonstrably clear that the > announcement should have been sent much, much earlier. I don't think this I-D would change this for the better or worse. Since it is happening now one would hope that it wouldn't be worse if this I-D is ratified. > Hence, having people who are practicing FULL disclosure is very useful > thing, in that if the process gets abused, or the coordinator gets > captured by the vendors and attempts to try to keep something secret for > too long, there's a natural, and LEGAL way for the knowledge to be > disseminated outside of the semi-closed process. > > The problem with the IETF publishing a document, with the full > imprimatur of RFC status, is that it may reprecussions in the real world > that may not be desireable. At the minimum, it may cause people who > disclosure full disclosure to be subject to lawsuits based on the fact > that they had violated this particular RFC, and had therefore acted > "irresponsibility". It would be absolutely disastrous if some number of > federal or state legislatures used this document as model legislation > which prohibited any other form of disclosure but what has been > described in this document as "responsible". So if we do nothing the hope is the governments of the world will do nothing in concert. I think this is wishful thinking. If this I-D can help bring order to the disclosure process it has a chance of actually staving off legislation. I have a problem with the concept of full disclosure being a useful thing or a "necessary evil". Who gets to decide which users are the "collateral damage" for the next jolt to the system? This is the kind of out of control process that the government will want to regulate. > So imagine if you will a world where a vendor and coordinator act in bad > faith --- it would be really, really, bad if the person who finds the > security bug finds themselves forbidden from bypassing the vendor and > coordinator due to laws or threats of lawsuits which were facilitated by > the publication of this document with the IETF blessing. Reporters don't need to use coordinators. That is optional in the document. > As a result, I don't believe the IETF should publish this document, > regardless of how it might be tweaked. While it may be useful to have a > document which describes a process for doing semi-closed reporting, the > possibility that it might be used by companies (such as Microsoft, > reportedly) who have been lobbying governments to outlaw full disclosure > is so horrible that it outweighs, in my opinions, any positive value > which publishing this document might have. > > Personally speaking, I primarily participate in what this document calls > "responsible disclosure", but I want that to be my choice, not something > where the IETF, and maybe later on the U.S. Government, tells me that > it's something that I MUST do. There will always be special cases which > any process document cannot cover, and so I want the escape hatch to be > always a possibility. If these special cases can be outlined it could be added to the document. If new cases come in the future that we have no way of knowing now the RFC should be revised. > I suppose we could fix this by adding the following disclaimer at the > beginning of the document: > > "At any point in time, the reporter MAY choose to make the > vulnerability public, for any reason, and via any forum at the > reporter's discretion, and this will also be considered > 'responsble reporting'." > > With this kind of "First Amendment" guarantee in the document, it might > be acceptable to have the IETF publish such a document. But somehow I > doubt the authors would be willing to put such an exception in their > document..... The whole thing is volutary anyway. We could eliminate the 'responsible reporting' verbage to get the same effect you are seeking. > At the very least the SAAG and the authors should very carefully > consider the MUST's and SHOULD's, and meditate on whether or not they > would mind being thrown jail for five years, or sued for ten million > dollars, if they happened to violate any of the MUST's or SHOULD's in > the document. If you're not comfortable with that, then maybe it should > be dropped from the document --- and maybe the document should be > dropped entirely. Certainly. -Chris > > - Ted > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > From Pekka.Nikander@nomadiclab.com Mon Feb 25 02:36:20 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id CAA11103 for ; Mon, 25 Feb 2002 02:36:20 -0500 (EST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA21751 for ; Mon, 25 Feb 2002 02:36:19 -0500 (EST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id E827DA for ; Mon, 25 Feb 2002 09:38:11 +0200 (EET) Message-ID: <3C79E93E.20905@nomadiclab.com> Date: Mon, 25 Feb 2002 09:35:26 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > As a result, I don't believe the IETF should publish this document, > regardless of how it might be tweaked. While it may be useful to have a > document which describes a process for doing semi-closed reporting, the > possibility that it might be used by companies (such as Microsoft, > reportedly) who have been lobbying governments to outlaw full disclosure > is so horrible that it outweighs, in my opinions, any positive value > which publishing this document might have. Without wanting to get involved in the debate, I just want to express that I completely agree with Ted's comment above. Personally, I do not believe that it is possible to get even rough consensus on this issue. Therefore, IMHO, it would be best to drop the discussion within IETF, and continue it somewhere else. --Pekka Nikander From rlmorgan@washington.edu Mon Feb 25 03:35:37 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id DAA11757 for ; Mon, 25 Feb 2002 03:35:36 -0500 (EST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id DAA19126 for ; Mon, 25 Feb 2002 03:35:36 -0500 (EST) Received: from mailscan-out2.cac.washington.edu (mailscan-out2.cac.washington.edu [140.142.33.17]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g1P8ZZeH008200 for ; Mon, 25 Feb 2002 00:35:35 -0800 Received: FROM smtp.washington.edu BY mailscan-out2.cac.washington.edu ; Mon Feb 25 00:35:35 2002 -0800 Received: from [192.168.1.102] (12-228-196-85.client.attbi.com [12.228.196.85]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g1P8ZWjv021422 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 25 Feb 2002 00:35:34 -0800 Date: Mon, 25 Feb 2002 00:36:40 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perx.cac.washington.edu To: SAAG list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] [Last Call on SAML 1.0 Specification] Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: The Security Assertion Markup Language (SAML) specification is being developed in the OASIS standards organization, and is likely to be of interest to some SAAG readers. It specifies XML schema for a set of security assertions (Authentication, Attribute, Authorization Decision), a simple query/response protocol, and a profile for using assertions for signon using regular web browsers. The committee's home page is at: http://www.oasis-open.org/committees/security/ The message below announces Last Call (more or less equivalent to IETF WG Last Call) on the SAML 1.0 document set, and includes instructions on how to provide comments. Review and comments from SAAGsters are encouraged. - RL "Bob" ---------- Forwarded message ---------- Date: Thu, 21 Feb 2002 10:54:21 -0800 From: Jeff Hodges Subject: [security-services] Committee Last Call on SAML 1.0 Specification Set (20-Feb-2002) The purpose of this message is to initiate the Security Services Technical Committee Last Call on the SAML 1.0 Specification Set (20-Feb-2002). WHAT SPECIFICATION SET? The specification set in last call is the SAML 1.0 Specification Set (20-Feb-2002): http://www.oasis-open.org/committees/security/docs/draft-sstc-core-27.pdf http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-assertion-27.xsd http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-protocol-27.xsd http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model-11.pdf http://www.oasis-open.org/committees/security/docs/draft-sstc-sec-consider-04.pdf http://www.oasis-open.org/committees/security/docs/draft-sstc-conform-spec-11.pdf http://www.oasis-open.org/committees/security/docs/draft-sstc-glossary-02.pdf The relevant Issues List docs are: http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-issues-08.pdf http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-issues-status-03.pdf WHAT IS A COMMITTEE LAST CALL FOR? The purpose of the committee last call is to ensure that the committee has reached consensus on the documents comprising the specification set, believes that all the known outstanding issues have been addressed, and is ready to vote on declaring the documents as "Committee Specifications" in preparation for submission to OASIS-wide review. During the last call, any comments on the documents are collected and discussed on the mailing lists. HOW LONG DOES IT LAST? The last call starts today 21-Feb-2002 and will last approximately two weeks. It will end on Thursday, 7-Mar-2002, the "Last Call cut-off date". WHAT'S THE LAST CALL PROCESS AND NEXT STEPS? The Committee Last Call process we're following is described here.. SSTC "Committee Last Call" process http://lists.oasis-open.org/archives/security-services/200202/msg00176.html WHAT SHOULD YOU DO? You should read the documents, making sure that (1) there are no normative problems or deficiencies or outstanding issues that need to be resolved; and (2) that there are no typos, formatting problems, grammatical errors, etc. Send notice of any issues you find, normative or otherwise, to the appropriate list (see below). WHERE DO I SEND MY COMMENTS? OASIS SSTC members should send their comments to the.. security-services@lists.oasis-open.org ..mailing list. List archives are available here.. http://lists.oasis-open.org/archives/security-services/ NOTE: Only subscribers may post to the security-services list. However, any OASIS member may subscribe to the security-services list. To subscribe, send an email message to.. security-services-request@lists.oasis-open.org ..with the word "subscribe" as the body of the message. The general public ("reviewers at-large") should send comments to.. security-services-comment@lists.oasis-open.org NOTE: Before sending messages to the security-services-comment list, YOU MUST FIRST SUBSCRIBE. To subscribe, send an email message to.. security-services-comment-request@lists.oasis-open.org ..with the word "subscribe" as the body of the message. Archives of the security-services-comment list are available here.. http://lists.oasis-open.org/archives/security-services-comment/ Archives for all SSTC mailing lists are described here.. http://www.oasis-open.org/committees/security/#mailinglists Read, enjoy, and send your comments in! regards, Jeff Hodges and Joe Pato From aleph1@securityfocus.com Mon Feb 25 04:14:49 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA12102 for ; Mon, 25 Feb 2002 04:14:49 -0500 (EST) From: aleph1@securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id EAA22969 for ; Mon, 25 Feb 2002 04:14:48 -0500 (EST) Received: (qmail 9743 invoked by uid 101); 25 Feb 2002 09:13:15 -0000 Date: Mon, 25 Feb 2002 02:13:15 -0700 To: Chris Wysopal Cc: tytso@mit.edu, saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Message-ID: <20020225091315.GB20167@securityfocus.com> References: <3C79DE64.4000403@atstake.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C79DE64.4000403@atstake.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: * Chris Wysopal (cwysopal@atstake.com) [020225 06:58]: > > I have a problem with the concept of full disclosure being a useful thing > or a "necessary evil". Who gets to decide which users are the "collateral > damage" for the next jolt to the system? This is the kind of out of control > process that the government will want to regulate. And who gets to decide whether users get detailed technical information they may need? Wysopal and Christie? Thats the type of control over information I don't want the government or corporations to have. -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum From rja@extremenetworks.com Mon Feb 25 08:35:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA14488 for ; Mon, 25 Feb 2002 08:35:34 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA23129; Mon, 25 Feb 2002 08:35:34 -0500 (EST) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 5D44F67103; Mon, 25 Feb 2002 08:55:01 -0500 (EST) Date: Mon, 25 Feb 2002 08:35:30 -0500 Mime-Version: 1.0 (Apple Message framework v481) Cc: saag@mit.edu Message-Id: <8961EBA1-29F4-11D6-92F1-00039357A82A@extremenetworks.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea From: RJ Atkinson Content-Transfer-Encoding: 7bit To: tytso@mit.edu X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I agree with Ted's analysis and conclusions. The above document does not belong in the IETF or as an RFC. If it is published as an RFC by the RFC Editor, there ought to be an IESG tombstone making it expressly clear that the document does NOT reflect any sort of IETF consensus and that there is in actual fact nothing resembling consensus in the IETF community about what sort of disclosures are or aren't responsible. Ran From cwysopal@atstake.com Mon Feb 25 11:53:21 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA16998 for ; Mon, 25 Feb 2002 11:53:21 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id LAA28354 for ; Mon, 25 Feb 2002 11:53:20 -0500 (EST) Received: (qmail 29667 invoked from network); 25 Feb 2002 16:56:08 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 25 Feb 2002 16:56:08 -0000 Received: from atstake.com (ssh-gw.atstake.com [63.168.6.76]) by cam-relay.atstake.com (Postfix) with SMTP id 1994A22818; Mon, 25 Feb 2002 11:52:33 -0500 (EST) Message-ID: <3C7A6C09.1060802@atstake.com> Date: Mon, 25 Feb 2002 08:53:29 -0800 From: Chris Wysopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Pekka Nikander Cc: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea References: <3C79E93E.20905@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Pekka Nikander wrote: > Personally, I do not believe that it is possible to get even rough > consensus on this issue. Therefore, IMHO, it would be best to drop > the discussion within IETF, and continue it somewhere else. Currently in the industry there IS rough consensus on the issue. At least when it comes to process. Let's stay away from content since that isn't the subject of this I-D. There are ad-hoc processes in place that mostly work when there is someone experienced on both the vendor and reporter sides. Documenting these processes in a BCP, even loosely, helps everyone involved work together to lower the risk to the system as a whole. -Chris > --Pekka Nikander > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag From rja@extremenetworks.com Mon Feb 25 12:53:09 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA17935 for ; Mon, 25 Feb 2002 12:53:08 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA26539 for ; Mon, 25 Feb 2002 12:53:08 -0500 (EST) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 8A5CC67103; Mon, 25 Feb 2002 13:12:37 -0500 (EST) Date: Mon, 25 Feb 2002 12:53:05 -0500 Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Pekka Nikander , saag@mit.edu To: Chris Wysopal From: RJ Atkinson In-Reply-To: <3C7A6C09.1060802@atstake.com> Message-Id: <856B0773-2A18-11D6-A901-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Monday, February 25, 2002, at 11:53 , Chris Wysopal wrote: > Currently in the industry there IS rough consensus on the issue. At > least when it comes to process. There is not within the IETF right now -- and IETF consensus is the metric for IETF-related documents -- not some other consensus (where many would even dispute that the other consensus you stipulate actually exists). > Documenting these processes in a BCP, even loosely, helps everyone > involved work together to lower the risk to the system as a whole. Your claim is not at all the case. For CERT or CIAC or other such like to document their own processes (which VARY, by the way) in their own document series would be quite reasonable, however. This sort of thing isn't properly an IETF matter, as Ted and others already outlined in detail. Ran From pbaker@verisign.com Mon Feb 25 13:28:47 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA18462 for ; Mon, 25 Feb 2002 13:28:47 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA11092 for ; Mon, 25 Feb 2002 13:28:47 -0500 (EST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g1PIP7R10062; Mon, 25 Feb 2002 10:25:07 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <15Y113XW>; Mon, 25 Feb 2002 10:29:45 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869971@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Paul Hoffman / IMC'" , "Steven M. Christey" , saag@mit.edu Subject: RE: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Date: Mon, 25 Feb 2002 10:29:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BE2A.5C21D6F0" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BE2A.5C21D6F0 Content-Type: text/plain; charset="iso-8859-1" I agree with Paul, however Paul should realise that what he is asking for is impossible. A couple of years ago I circulated a first draft of a specification that was 10 pages long. After the review committee chopped the scope of the specification down to a small fraction of the original I ended up with a draft of only 50 pages. The full set of specifications that originate from those 10 pages are now over 300 pages in length and growing with each attempt to prune them. I think that there is a fundamental problem here, but the people who are going to read the draft are not the cause of it. At best the draft can provide cover for people being unfairly accused of being irresponsible. The draft does not provide balance in the form of denigrating grossly irresponsible grandstanding and bad journalism. I don't think that a 'responsible disclosure' draft has much credibility unless it also defines what irresponsible disclosure is. The 'full disclosure' mantra is already far too close to religion. If normative ethics was that simple they would be teaching it in grade school. There is certainly a point where 'full disclosure' starts to become close to the mode of cracking favored by elite hackers who do not use the virus or other exploit code themselves but make it available to as many lamers as possible. I think that the bad journalism angle has to be more fully addressed. In many cases journalists are publishing reports of 'security bugs' they cannot possibly be in a position to evaluate from sources whose motives are exceptionaly suspect. For example a couple of days after the release of Visual Studio .net we see a headling that claims the program has been 'broken' and a story that reports that some obscure 'expert' looking for publicity has analysed the compiler and discovered that it uses a 'stack guard' technique which has been previously broken. What the story does not say is if the previous attacks have been shown to work on Visual Studio .net, unless one assumes that this must have happened if the headline is true, only we all know how headlines are generated in trade rags. Nor are we told if the stack guard technique is a first line of defense or a safeguard in case of another failure such as a buffer overflow. The other issue I think needs to be addressed is the issue of disclosure of security issues that are specific to particular installations. I don't think that the 'full disclosure' dogma justifies unearthing security holes in a specific site that you have no legitimate interest in and broadcasting them to the world. But I see people attempting to use it to justify making accusations that are usually unustified and frequently so vague as to be meaningless against companies that don't even sell software and certainly never solicited security advice from the source in question. In particular when I did security work for a government site I was not at all pleased when a security expert who I won't name decided to volunteer in a public forum that he had detected specific security weaknesses at the site. In that particular case the accusations was actually false and he appeared to either be gambling that there would be no rebuttal or had not anticipated that a high security site might well have countermeasures against the naive port scanning technique he was using. The effect was still tantamount to a DoS attack with the number of penetration attempts rising by a couple of orders of magnitude over the following week. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Paul Hoffman / IMC [mailto:phoffman@imc.org] > Sent: Friday, February 22, 2002 9:12 PM > To: Steven M. Christey; saag@mit.edu > Subject: [saag] Re: Internet-Draft for "Responsible > Disclosure Process" > released > > > To echo what a few other people have said: why is this document so > long? It sounds more like a white paper than short, crisp definition > of Best Current Practices. Lots of the material is statements that > are easy for Company A to agree with but Company B to disagree with, > or Reporter C to agree with but Reporter D to disagree with. > > Suggestion: make it about five pages long. Name the parties, give a > timeline template, list the timers, describe who can do what in the > various failure states, and say "people will have different reasons > for complying and not complying with this". > > --Paul Hoffman, Director > --Internet Mail Consortium > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > ------_=_NextPart_000_01C1BE2A.5C21D6F0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BE2A.5C21D6F0-- From phoffman@imc.org Mon Feb 25 13:50:45 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA18784 for ; Mon, 25 Feb 2002 13:50:45 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA18605 for ; Mon, 25 Feb 2002 13:50:44 -0500 (EST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PIof305662 for ; Mon, 25 Feb 2002 10:50:41 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <856B0773-2A18-11D6-A901-00039357A82A@extremenetworks.com> References: <856B0773-2A18-11D6-A901-00039357A82A@extremenetworks.com> Date: Mon, 25 Feb 2002 10:50:40 -0800 To: saag@mit.edu From: Paul Hoffman / IMC Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: BCP RFCs are tricky and the guidelines for them being issued are far from clear. In the current case, it is not clear that we have had much experience with the various practices to be able to say which one we think is best. Ted's point about the fact that the many different practices in existence today help each other should certainly make us think about not cutting out some of those practices. As Ran said, if this is going to be published by the IETF as a BCP, it should at least be a reflection of what interested IETFers think is "best", and it is clear that there is no consensus there. I proposed narrowing *the draft* to a few pages to see if consensus could be reached before we even thought about it as an RFC, but recent messages show that the authors want to keep adding interesting things to the draft. That is bad for an IETF protocol, and bad for an IETF BCP. Next there will be the oft-heard chorus of "so let's publish it as an Informational RFC". And that should be followed with the counter-chorus (or whatever the correct musical term is) of "that is an abuse of Informational RFC status". Information that has been discussed on an IETF mailing list doesn't need to turn into an RFC, particularly when there was little agreement on it. If there is a strong community need to be able to refer to this document once it stabilizes, it should be codified somewhere else, possibly on an interestingly-named web site or simply as part of the well-established security and crypto sites. --Paul Hoffman, Director --Internet Mail Consortium From cwilliamson@limited.com Mon Feb 25 14:04:01 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA19038 for ; Mon, 25 Feb 2002 14:04:01 -0500 (EST) Received: from ns1.limited.com (colsmtp.limited.com [63.72.208.21]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA14805 for ; Mon, 25 Feb 2002 14:04:01 -0500 (EST) Received: from [10.128.12.151] ([192.168.6.25]) by ns1.limited.com (Switch-2.1.1/Switch-2.1.1) with ESMTP id U1PJ13E717820; Mon, 25 Feb 2002 14:03:50 -0500 Subject: RE: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released From: "D. Clyde Williamson" To: "Hallam-Baker, Phillip" Cc: saag@mit.edu In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869971@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F405869971@vhqpostal.verisign.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KzzRHi97/0oykZlvAhwe" X-Mailer: Evolution/1.0.2 Date: 25 Feb 2002 14:03:43 -0500 Message-Id: <1014663831.10764.105.camel@jabberwock> Mime-Version: 1.0 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: --=-KzzRHi97/0oykZlvAhwe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-02-25 at 13:29, Hallam-Baker, Phillip wrote: > I think that there is a fundamental problem here, but the people who are > going to read the draft are not the cause of it. At best the draft can > provide cover for people being unfairly accused of being irresponsible. T= he > draft does not provide balance in the form of denigrating grossly > irresponsible grandstanding and bad journalism. >=20 > I think that the bad journalism angle has to be more fully addressed. In > many cases journalists are publishing reports of 'security bugs' they can= not > possibly be in a position to evaluate from sources whose motives are > exceptionaly suspect. Ohhh, trying to tell journalists what is and is not the correct way to report issues? Methinks, they could easily yell the First and say that in reality, the purpose of the document was to cover up security flaws that the public should know about. Big yuchhy mess. >=20 > The other issue I think needs to be addressed is the issue of disclosure = of > security issues that are specific to particular installations. >=20 > I don't think that the 'full disclosure' dogma justifies unearthing secur= ity > holes in a specific site that you have no legitimate interest in and > broadcasting them to the world. But I see people attempting to use it to > justify making accusations that are usually unustified and frequently so > vague as to be meaningless against companies that don't even sell softwar= e > and certainly never solicited security advice from the source in question= . Well, if this is the case... I'll run a banking site, never bother to secure it properly, and make sure I never ask any security experts to look at it. After all, it's only the users who are at risk. No reason anyone should think to alert them to the potential security problems. And if anyone does... I'll use this document to prove that they are Black Hat Hackers, one step down from Osama Bin Laden. :-/ This is just silly. If I find an insecure online banking system, shopping cart, whatever... I'm not simply going to say "Well, its none of my business and walk away. THAT is irresponsible. If I do alert the company and they decide to ignore me... it would be irresponsible to leave the poor end users at the mercy of the company.=20 There is a proper and imporper way to deal with security issues. However, I believe that the proper/improper way is different for each situation. It depends on too many variables to try to document out the "One Best Way". --=20 D. Clyde Williamson Information Security Group The Limited, Inc. "Just because you're paranoid, it doesn't mean we aren't watching you." --=-KzzRHi97/0oykZlvAhwe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUAPHqKj2JCdUlJnIZxEQIy8wCcCWa7Do2b43jwcRxfU+13EAJDl+wAoPYd whujSxK9cTfmQ8W3y5FBG5fR =aDIq -----END PGP SIGNATURE----- --=-KzzRHi97/0oykZlvAhwe-- From tytso@thunk.org Mon Feb 25 14:23:41 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA19357 for ; Mon, 25 Feb 2002 14:23:41 -0500 (EST) Received: from thunk.org (THUNK.ORG [216.175.175.175]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA04450; Mon, 25 Feb 2002 14:23:40 -0500 (EST) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.34 #1 (Debian)) id 16fQio-0004xW-00; Mon, 25 Feb 2002 14:23:38 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16fQio-0000SP-00; Mon, 25 Feb 2002 14:23:38 -0500 Date: Mon, 25 Feb 2002 14:23:38 -0500 From: Theodore Tso To: Chris Wysopal Cc: tytso@mit.edu, saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Message-ID: <20020225142338.A1701@thunk.org> References: <3C79DE64.4000403@atstake.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3C79DE64.4000403@atstake.com>; from cwysopal@atstake.com on Sun, Feb 24, 2002 at 10:49:09PM -0800 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Sun, Feb 24, 2002 at 10:49:09PM -0800, Chris Wysopal wrote: > > Can we just call it a Best Current Practice document and not a policy > document? But it's *not* the Best Current Practice --- or rather, there is currently no consensus that it is the Best Current Practice. That's my whole point! In fact, calling it a Best Current Practice would worsen the situation, since it's an even stronger statement than "Informational RFC" --- and I don't believe it should even be given that much of a stamp of approval. >There certainly is a range of dealing with security bugs and not one >single process. Perhaps the document needs to be more flexible to >encompass a wider range. We could fix your document by deleting much of the detail, and being fair about giving equal are time about full disclosure practices, and there are those who believe that due to the past history of irresponsible, or at least unwise, actions by vendors AND coordinators, the reporters should be given the flexibility to engage in full disclosure as well. So yes, if we can make the document that flexible, then it can be salvaged. > > Indeed, I've seen cases (as recently as in the past month) where a > > coordinator arguably abused its discretion by suppressing knowledge of a > > security bug for what seemed to be inappropriately long periods --- in > > fact, to the point where it became demonstrably clear that the > > announcement should have been sent much, much earlier. > > I don't think this I-D would change this for the better or worse. Since > it is happening now one would hope that it wouldn't be worse if this I-D > is ratified. Having this I-D progress will make things worse, because the reporter must be able to step outside the process. To the extent that this makes it easier for governments to pass laws MANDATING what the you'd like to call called "Best Current Practice", or "Responsible Reporting", or may increase the reporter's liability risks, such that it might make stepping outside of the process no longer possible. And that would be a disaster. > So if we do nothing the hope is the governments of the world will do > nothing in concert. I think this is wishful thinking. If this I-D can > help bring order to the disclosure process it has a chance of actually > staving off legislation. I don't disagree think that nothing should be done. I simply disagree that your paper will help the situation. In fact, I think it will hurt. A lot. An alternative document which treats both semi-closed and full disclosure processes as being on equal status, and stating that there is *no* consensus in the security community as a whole about which was better might be a very, very, good thing. Such a paper would hopefully serve to inject clue into this public policy debate, which would otherwise only be influenced by the no doubt vast sums of money by corporations such as Microsoft who have spent lobbying to pass laws to gag people who find security vulnerabilities in their products. >Currently in the industry there IS rough consensus on the issue. At >least when it comes to process. Let's stay away from content since that >isn't the subject of this I-D. There are ad-hoc processes in place that >mostly work when there is someone experienced on both the vendor and >reporter sides. Documenting these processes in a BCP, even loosely, >helps everyone involved work together to lower the risk to the system as >a whole. If by industry you mean the "vendors" and "coordinators", I would agree. In fact, I'm sure many vendors would prefer if any details security vulnerabilities were never to slip out at all. And coordinators need to invent some kind of process because that's how they make their money --- either by taking money from the vendors (which influences them inevitably, if subtly, towards taking the side of the vendors), or by selectively giving information out to their "paying customers" (which influences them to wanting to keep the secrecy window as long as possible, in order to deliver maximal value to their customers who put bread on their table). But I think we need to consider the security community as a whole, not just "the industry". I also reject your claim that "full disclosure" is just about content. It is also very much about the process. Given the huge amounts of resources which the vendors and coordinators have (they either *are* or are funded big businesses, after all), any kind of process will inevitably be weighted (or will become twisted) to end up in favor of the vendors and coordinators to the detriment of all others. So the reporter must always be given the opportunity to step outside of the process; and if we're going to specify a process, it must always be OK for the reporter, at any step of the process, to bypass both the vendor and the coordinator, and talk to the public (i.e., the users and system administration community) directly. This will serve as a check and balance to make sure that the vendor and coordinator are always acting in good faith; if they aren't, the reporter will have the recourse of simply disclosing all to the public immediately. > > I suppose we could fix this by adding the following disclaimer at the > > beginning of the document: > > > > "At any point in time, the reporter MAY choose to make the > > vulnerability public, for any reason, and via any forum at the > > reporter's discretion, and this will also be considered > > 'responsble reporting'." > > > > With this kind of "First Amendment" guarantee in the document, it might > > be acceptable to have the IETF publish such a document. But somehow I > > doubt the authors would be willing to put such an exception in their > > document..... > > The whole thing is volutary anyway. We could eliminate the 'responsible > reporting' verbage to get the same effect you are seeking. It's voluntary *today*. My concern is that after the document is published, it might become involuntary. Hence, my belief that it needs to be analyzed from the perspective of whether we'd be happy living in a world where it effectively becomes the only way that security vulnerabilities could be treated. Vendors might be ecstatic; others might not be so happy. - Ted From cwysopal@atstake.com Mon Feb 25 14:38:56 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA19612 for ; Mon, 25 Feb 2002 14:38:56 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id OAA11489 for ; Mon, 25 Feb 2002 14:38:55 -0500 (EST) Received: (qmail 31206 invoked from network); 25 Feb 2002 19:41:43 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 25 Feb 2002 19:41:43 -0000 Received: from atstake.com (ssh-gw.atstake.com [63.168.6.76]) by cam-relay.atstake.com (Postfix) with SMTP id CAB0F22818; Mon, 25 Feb 2002 14:37:06 -0500 (EST) Message-ID: <3C7A92A7.3090705@atstake.com> Date: Mon, 25 Feb 2002 11:38:15 -0800 From: Chris Wysopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Hoffman / IMC Cc: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea References: <856B0773-2A18-11D6-A901-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steve Christey and I took some of our cues from documents like BCP 46, "Recommended Internet Service Provider Security Services and Procedures" This document uses the SHOULD language. Some of the the issues documented are not technical in nature, but procedural. It codifies best ISP security practices for newbie ISPs that would otherwise need to learn the hard way. Good ISP practices lower the security risk for the Internet as a whole because of its community nature. One of the goals Steve Christey and I had was to create a document that was a reference for newbie reporters and vendors. It is often unnecessarily painful and sometimes disastrous to either reporter or vendor when one of the parties is sending or receiving a report for the first time. Like ISP security practices, vulnerability reporting and disclosure practices have the potential to lower the risk for the Internet as a whole. But as you say there needs to be some consensus within the IETF for it to be an IETF document of any type. -Chris Paul Hoffman / IMC wrote: > BCP RFCs are tricky and the guidelines for them being issued are far from clear. > > In the current case, it is not clear that we have had much experience with the various practices to be able to say which one we think is best. > Ted's point about the fact that the many different practices in existence > today help each other should certainly make us think about not cutting > out some of those practices. > > As Ran said, if this is going to be published by the IETF as a BCP, > it should at least be a reflection of what interested IETFers think > is "best", and it is clear that there is no consensus there. I > proposed narrowing *the draft* to a few pages to see if consensus > could be reached before we even thought about it as an RFC, but > recent messages show that the authors want to keep adding > interesting things to the draft. That is bad for an IETF protocol, > and bad for an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as an Informational RFC". And that should be followed with the counter-chorus > (or whatever the correct musical term is) of "that is an abuse of > Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't need > to turn into an RFC, particularly when there was little agreement on it. > If there is a strong community need to be able to refer to this document > once it stabilizes, it should be codified somewhere else, possibly on an > interestingly-named web site or simply as part of the well-established > security and crypto sites. > > --Paul Hoffman, Director > --Internet Mail Consortium > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > > from clear. > > In the current case, it is not clear that we have had much > experience with the various practices to be able to say which one > we think is best. Ted's point about the fact that the many > different practices in existence today help each other should > certainly make us think about not cutting out some of those > practices. > > As Ran said, if this is going to be published by the IETF as a BCP, > it should at least be a reflection of what interested IETFers > think is "best", and it is clear that there is no consensus there. > I proposed narrowing *the draft* to a few pages to see if > consensus could be reached before we even thought about it as an > RFC, but recent messages show that the authors want to keep adding > interesting things to the draft. That is bad for an IETF > protocol, and bad for an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as > an Informational RFC". And that should be followed with the > counter-chorus (or whatever the correct musical term is) of "that > is an abuse of Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't > need to turn into an RFC, particularly when there was little > agreement on it. If there is a strong community need to be able to > refer to this document once it stabilizes, it should be codified > somewhere else, possibly on an interestingly-named web site or > simply as part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag > > > with the various practices to be able to say which one we think > is best. Ted's point about the fact that the many different > practices in existence today help each other should certainly make > us think about not cutting out some of those practices. > > As Ran said, if this is going to be published by the IETF as a BCP, > it should at least be a reflection of what interested IETFers think > is "best", and it is clear that there is no consensus there. I > proposed narrowing *the draft* to a few pages to see if consensus > could be reached before we even thought about it as an RFC, but > recent messages show that the authors want to keep adding > interesting things to the draft. That is bad for an IETF protocol, > and bad for an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as an Informational RFC". And that should be followed with the counter-chorus > (or whatever the correct musical term is) of "that is an abuse of > Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't need > to turn into an RFC, particularly when there was little agreement on it. > If there is a strong community need to be able to refer to this document > once it stabilizes, it should be codified somewhere else, possibly on an > interestingly-named web site or simply as part of the well-established > security and crypto sites. > > --Paul Hoffman, Director > --Internet Mail Consortium > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > > from clear. > > In the current case, it is not clear that we have had much > experience with the various practices to be able to say which one > we think is best. Ted's point about the fact that the many > different practices in existence today help each other should > certainly make us think about not cutting out some of those > practices. > > As Ran said, if this is going to be published by the IETF as a BCP, > it should at least be a reflection of what interested IETFers > think is "best", and it is clear that there is no consensus there. > I proposed narrowing *the draft* to a few pages to see if > consensus could be reached before we even thought about it as an > RFC, but recent messages show that the authors want to keep adding > interesting things to the draft. That is bad for an IETF > protocol, and bad for an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as > an Informational RFC". And that should be followed with the > counter-chorus (or whatever the correct musical term is) of "that > is an abuse of Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't > need to turn into an RFC, particularly when there was little > agreement on it. If there is a strong community need to be able to > refer to this document once it stabilizes, it should be codified > somewhere else, possibly on an interestingly-named web site or > simply as part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag > > > Informational RFC". And that should be followed with the > counter-chorus (or whatever the correct musical term is) of "that > is an abuse of Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't > need to turn into an RFC, particularly when there was little > agreement on it. If there is a strong community need to be able to > refer to this document once it stabilizes, it should be codified > somewhere else, possibly on an interestingly-named web site or > simply as part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag > >> from clear. > > In the current case, it is not clear that we have had much experience > with the various practices to be able to say which one we think > is best. Ted's point about the fact that the many different > practices in existence today help each other should certainly make > us think about not cutting out some of those practices. > > As Ran said, if this is going to be published by the IETF as a BCP, it > should at least be a reflection of what interested IETFers think > is "best", and it is clear that there is no consensus there. I > proposed narrowing *the draft* to a few pages to see if consensus > could be reached before we even thought about it as an RFC, but > recent messages show that the authors want to keep adding interesting > things to the draft. That is bad for an IETF protocol, and bad > for an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as an > Informational RFC". And that should be followed with the counter-chorus > (or whatever the correct musical term is) of "that is an abuse of > Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't need > to turn into an RFC, particularly when there was little agreement > on it. If there is a strong community need to be able to refer to > this document once it stabilizes, it should be codified somewhere > else, possibly on an interestingly-named web site or simply as > part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > > > Informational RFC". And that should be followed with the > counter-chorus (or whatever the correct musical term is) of "that > is an abuse of Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't > need to turn into an RFC, particularly when there was little > agreement on it. If there is a strong community need to be able to > refer to this document once it stabilizes, it should be codified > somewhere else, possibly on an interestingly-named web site or > simply as part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag > >> from clear. > > In the current case, it is not clear that we have had much experience > with the various practices to be able to say which one we think > is best. Ted's point about the fact that the many different > practices in existence today help each other should certainly make > us think about not cutting out some of those practices. > > As Ran said, if this is going to be published by the IETF as a BCP, it > should at least be a reflection of what interested IETFers think > is "best", and it is clear that there is no consensus there. I > proposed narrowing *the draft* to a few pages to see if consensus > could be reached before we even thought about it as an RFC, but > recent messages show that the authors want to keep adding interesting > things to the draft. That is bad for an IETF protocol, and bad > for an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as an > Informational RFC". And that should be followed with the counter-chorus > (or whatever the correct musical term is) of "that is an abuse of > Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't need > to turn into an RFC, particularly when there was little agreement > on it. If there is a strong community need to be able to refer to > this document once it stabilizes, it should be codified somewhere > else, possibly on an interestingly-named web site or simply as > part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > >> with the various practices to be able to say which one we think > is best. Ted's point about the fact that the many different practices > in existence today help each other should certainly make us think > about not cutting out some of those practices. > > As Ran said, if this is going to be published by the IETF as a BCP, it > should at least be a reflection of what interested IETFers think is > "best", and it is clear that there is no consensus there. I proposed > narrowing *the draft* to a few pages to see if consensus could be > reached before we even thought about it as an RFC, but recent > messages show that the authors want to keep adding interesting > things to the draft. That is bad for an IETF protocol, and bad for > an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as an Informational RFC". And that should be followed with the counter-chorus > (or whatever the correct musical term is) of "that is an abuse of Informational > RFC status". > > Information that has been discussed on an IETF mailing list doesn't > need to turn into an RFC, particularly when there was little > agreement on it. If there is a strong community need to be able to > refer to this document once it stabilizes, it should be codified > somewhere else, possibly on an interestingly-named web site or > simply as part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag > >> from clear. > > In the current case, it is not clear that we have had much experience > with the various practices to be able to say which one we think > is best. Ted's point about the fact that the many different > practices in existence today help each other should certainly make > us think about not cutting out some of those practices. > > As Ran said, if this is going to be published by the IETF as a BCP, it > should at least be a reflection of what interested IETFers think > is "best", and it is clear that there is no consensus there. I > proposed narrowing *the draft* to a few pages to see if consensus > could be reached before we even thought about it as an RFC, but > recent messages show that the authors want to keep adding interesting > things to the draft. That is bad for an IETF protocol, and bad > for an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as an > Informational RFC". And that should be followed with the counter-chorus > (or whatever the correct musical term is) of "that is an abuse of > Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't need > to turn into an RFC, particularly when there was little agreement > on it. If there is a strong community need to be able to refer to > this document once it stabilizes, it should be codified somewhere > else, possibly on an interestingly-named web site or simply as > part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > >> Informational RFC". And that should be followed with the > counter-chorus (or whatever the correct musical term is) of "that is > an abuse of Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't need > to turn into an RFC, particularly when there was little agreement > on it. If there is a strong community need to be able to refer to > this document once it stabilizes, it should be codified somewhere > else, possibly on an interestingly-named web site or simply as part > of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > >> from clear. > > In the current case, it is not clear that we have had much experience with the various practices to be able to say which one we think > is best. Ted's point about the fact that the many different > practices in existence today help each other should certainly make > us think about not cutting out some of those practices. > > As Ran said, if this is going to be published by the IETF as a BCP, it > should at least be a reflection of what interested IETFers think > is "best", and it is clear that there is no consensus there. I > proposed narrowing *the draft* to a few pages to see if consensus > could be reached before we even thought about it as an RFC, but > recent messages show that the authors want to keep adding interesting > things to the draft. That is bad for an IETF protocol, and bad > for an IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as an > Informational RFC". And that should be followed with the counter-chorus > (or whatever the correct musical term is) of "that is an abuse of > Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't need > to turn into an RFC, particularly when there was little agreement > on it. If there is a strong community need to be able to refer to > this document once it stabilizes, it should be codified somewhere > else, possibly on an interestingly-named web site or simply as > part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > > with the various practices to be able to say which one we think is > best. Ted's point about the fact that the many different practices > in existence today help each other should certainly make us think > about not cutting out some of those practices. > > As Ran said, if this is going to be published by the IETF as a BCP, > it should at least be a reflection of what interested IETFers think is > "best", and it is clear that there is no consensus there. I proposed > narrowing *the draft* to a few pages to see if consensus could be > reached before we even thought about it as an RFC, but recent > messages show that the authors want to keep adding interesting things > to the draft. That is bad for an IETF protocol, and bad for an > IETF BCP. > > Next there will be the oft-heard chorus of "so let's publish it as an Informational RFC". And that should be followed with the counter-chorus > (or whatever the correct musical term is) of "that is an abuse of > Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't need > to turn into an RFC, particularly when there was little agreement > on it. If there is a strong community need to be able to refer to > this document once it stabilizes, it should be codified somewhere > else, possibly on an interestingly-named web site or simply as > part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > > Informational RFC". And that should be followed with the > counter-chorus (or whatever the correct musical term is) of "that > is an abuse of Informational RFC status". > > Information that has been discussed on an IETF mailing list doesn't > need to turn into an RFC, particularly when there was little > agreement on it. If there is a strong community need to be able to > refer to this document once it stabilizes, it should be codified > somewhere else, possibly on an interestingly-named web site or > simply as part of the well-established security and crypto sites. > > --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ > > saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag > > From aleph1@securityfocus.com Fri Feb 22 06:03:15 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA28566 for ; Fri, 22 Feb 2002 06:03:15 -0500 (EST) From: aleph1@securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id GAA27445 for ; Fri, 22 Feb 2002 06:03:14 -0500 (EST) Received: (qmail 13366 invoked by uid 101); 22 Feb 2002 11:02:05 -0000 Date: Fri, 22 Feb 2002 04:02:04 -0700 To: saag@mit.edu Subject: Re: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Message-ID: <20020222110204.GB7190@securityfocus.com> References: <20020221082930.GA24687@securityfocus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This is another error in this document. Steve said: > This touches on the usage of standardization language in this I-D. > It's not explicitly stated, but the thinking is: > > "Someone who agrees with the goals of responsible disclosure MUST > adhere to the key words specified in this document." > > i.e., there are specific expectations for any individual or > organization who wants to say that they practice responsible > disclosure. The corollary to this statement is that anyone that does not follow the process in this document is then "irresponsible". Since when is the IETF is the business of dictating morals? As I mentioned in my last message some people may have a very different idea of what is "responsible". For example, I don't particularly find "responsible" that CERT provides vulnerability information to companies that pay for access while the public has to wait[1]. (No offense Shawn) While the authors of this document and other may wish to make their idea of disclosure the "best current practice" labeling people that do not follow it as irresponsible and use the IETF weight to give that label legitimacy is wrong. The document needs to be renamed and a new term be used to describe what this document terms "responsible disclosure". [1] http://www.isalliance.org/ -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum From Michael.Cloppert@53.com Fri Feb 22 08:39:41 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA00015 for ; Fri, 22 Feb 2002 08:39:41 -0500 (EST) Received: from mail1.53.com ([192.152.100.14]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA22256 for ; Fri, 22 Feb 2002 08:39:41 -0500 (EST) Received: by CIN030 with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 08:39:41 -0500 Message-ID: <41ED4EB3C166D511BAC3009027DE9EBB05CDE877@cin098.info53.com> From: "Cloppert, Michael" To: "'saag@mit.edu'" Date: Fri, 22 Feb 2002 08:39:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [saag] suggestions for Responsible Vulnerability Disclosure Process Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: After reviewing this document by Steve Christey and Chris Wysopal, I came up with two very general suggestions. 1) I think there should be some allowance to skip the Notification, Validation, and Resolution stages if a vulnerability is discovered by the realization of some tool "in the wild" to exploit said vulnerability, and the Reporter believes this tool is or soon will be in wide circulation. 2) I would like to see something in the Follow-Up Phase requiring the testing of new versions of software against known vulnerabilities for previous versions as part of a Vendor's software development cycle. All in all, a very good paper. I would love to see this become an RFC and would encourage my employer to meet the responsibilities outlined for Customers, as well as Reporters and Coordinators when applicable. _______________________ Mike Cloppert Data Security Analyst Fifth Third Bank 513 534 0898 michael.cloppert@53.com From gopal.tadeparti@jpmobile.com Mon Feb 25 11:17:10 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA16486 for ; Mon, 25 Feb 2002 11:17:09 -0500 (EST) Received: from jpsmail.jpsystems.com ([209.184.70.163]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA11372 for ; Mon, 25 Feb 2002 11:17:09 -0500 (EST) Received: by JPSMAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 10:16:54 -0600 Message-ID: <1DDD2FAA45F4A44394FB7A5402DA6FC4142141@JPSMAIL> From: Gopal Tadeparti To: "'saag@mit.edu'" , "'leg+@andrew.cmu.edu'" Cc: "'ietf-sasl@imc.org'" Date: Mon, 25 Feb 2002 10:16:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [saag] saslauthd question Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I'm new to SASL. I want to set up cyrus IMAP server and use SASLv2 for authentication. I compiled SASLv2 with saslauthd option and installed it on solaris 5.7. When I try to start saslauthd with the following command >/usr/local/sbin/saslauthd -a shadow It gives the following error "saslauthd: /var/state/saslauthd: Not a directory" I don't know why saslauthd is looking in /var/state/ directory. I never set this in configuration. Please help me. From dclydew@columbus.rr.com Mon Feb 25 13:50:34 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA18777 for ; Mon, 25 Feb 2002 13:50:34 -0500 (EST) Received: from ns1.limited.com (colsmtp.limited.com [63.72.208.21]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA09265 for ; Mon, 25 Feb 2002 13:50:33 -0500 (EST) Received: from [10.128.12.151] ([192.168.6.18]) by ns1.limited.com (Switch-2.1.1/Switch-2.1.1) with ESMTP id U1PI2EO714710 for ; Mon, 25 Feb 2002 13:50:24 -0500 Subject: [Fwd: Re: [saag] The Responsible Disclosure draft: A Bad Idea] From: D Clyde Williamson To: saag@mit.edu Content-Type: multipart/mixed; boundary="=-uPBtXTkPNkM+TUVE78W7" X-Mailer: Evolution/1.0.2 Date: 25 Feb 2002 13:50:15 -0500 Message-Id: <1014663025.11162.89.camel@jabberwock> Mime-Version: 1.0 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: --=-uPBtXTkPNkM+TUVE78W7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Grrr, forgot to copy saag sorry -----Forwarded Message----- > From: D. Clyde Williamson > To: Chris Wysopal > Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea > Date: 25 Feb 2002 11:22:48 -0500 > > I've been a lurker on this list and I was planning on simply reading > this discussion. Unfortunately, my fingers decided that they were going > to respond. > > > On Mon, 2002-02-25 at 01:49, Chris Wysopal wrote: > > > > > > tytso@MIT.EDU wrote: > > > > > The IETF is an organization which whose primary strength is writing > > > protocols for the purposes of ensuring interoperability, not policy > > > documents, and writing a policy document in the style of a protocol, by > > > using RFC-2119 MUST/SHOULD language doesn't change the fact that it > > > isn't a protocol. > > > > > > The document could be rewritten to not use the RFC-2119 MUST/SHOULD > > language but precision is better than vagueness even in a BCP. > > It still doesn't change the fact that this really isn't what the IETF > does. The IETF is about creating standard protocols. It is not about > telling people how they 'should' act (that would be morals). Leave moral > training to religous leaders. > > > > > > Why is do I believe it is a bad idea for the IETF to publish a policy > > > document? First of all, it's not at all clear to me that it is a good > > > thing to standardize a single process for dealing with security bugs > > > (interoperability not being a major issue here), and in fact, I can > > > think of several bad reasons for this. > > > > > > Can we just call it a Best Current Practice document and not a policy > > document? There certainly is a range of dealing with security bugs and > > not one single process. Perhaps the document needs to be more flexible > > to encompass a wider range. > > It doesn't matter what you call it. It sets a dangerous preceedence for > any company to point to if someone decides not to follow it. Besides, > who are you (or we) to say it's the 'Best' Current Practice? > > > > > > Secondly, it closes a debate for which there is no consensus in the > > > community --- namely whether full, semi-full, or complete-closed > > > disclosure is the Right Answer. Even if someone participates primarily > > > in the semi-closed disclosure community, the fact that there are a number > > > of people who practice FULL disclosure is extremelly useful, because it > > > acts as a sanity check on those who practice semi-closed and closed > > > disclosure. > > > > > > I look at the full disclosure argument as more of a content issue than a > > process issue. The process in this document doesn't even recommend that > > a reporter not publish malicious worm code at vendor patch release > > time. It does specify that reporters should work with vendors to get > > the problem resolved before releasing information. This is a practice > > that is followed greater than 95% of the time currently. > > If its already being done... why write it down... If 95% of reporters > are already doing this.. why would we want to create a document to act > as a impediment to the other 5%? > > > > > > The problem with the IETF publishing a document, with the full > > > imprimatur of RFC status, is that it may reprecussions in the real world > > > that may not be desireable. At the minimum, it may cause people who > > > disclosure full disclosure to be subject to lawsuits based on the fact > > > that they had violated this particular RFC, and had therefore acted > > > "irresponsibility". It would be absolutely disastrous if some number of > > > federal or state legislatures used this document as model legislation > > > which prohibited any other form of disclosure but what has been > > > described in this document as "responsible". > > > > > > So if we do nothing the hope is the governments of the world will do > > nothing in concert. I think this is wishful thinking. If this I-D can > > help bring order to the disclosure process it has a chance of actually > > staving off legislation. > > > > I have a problem with the concept of full disclosure being a useful thing > > or a "necessary evil". Who gets to decide which users are the "collateral > > damage" for the next jolt to the system? This is the kind of out of control > > process that the government will want to regulate. > > You have a problem with it... thats fine, so you and the @Stake folks > don't do it. But, it's neither your place nor the IETF's to say that no > one can/should do it. > > > > > -- > D. Clyde Williamson > Information Security Group > The Limited, Inc. > > "Just because you're paranoid, it doesn't mean we aren't watching you." --=-uPBtXTkPNkM+TUVE78W7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogUEdQIDYuNS44CgppUUEvQXdV QVBIcGsxMkpDZFVsSm5JWnhFUUthNGdDZlZmKzI2UlV1ZTFrTUgwWW95UGlBak1LMU1wUUFvUHFz CmpxZkxWUUNwWHZqaDVsVEYyRFdJRHBLSAo9WVBhMwotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS0K --=-uPBtXTkPNkM+TUVE78W7-- From Kurt@OpenLDAP.org Mon Feb 25 14:52:25 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA20000 for ; Mon, 25 Feb 2002 14:52:25 -0500 (EST) Received: from pretender.boolean.net (router.boolean.net [198.144.206.49]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19272 for ; Mon, 25 Feb 2002 14:52:25 -0500 (EST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1PJqMC69930; Mon, 25 Feb 2002 19:52:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020225114246.017e5dc0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 11:52:26 -0800 To: Gopal Tadeparti From: "Kurt D. Zeilenga" Cc: "'saag@mit.edu'" , "'ietf-sasl@imc.org'" In-Reply-To: <1DDD2FAA45F4A44394FB7A5402DA6FC4142141@JPSMAIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [saag] Re: saslauthd question Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Please note that the lists you have posted are discussing IETF engineering work. Please direct questions specific to particular implementations of IETF protocols to forums supporting those implementations. The CMU Cyrus SASL implementation is support by the mailing list. Thanks, Kurt From rja@extremenetworks.com Mon Feb 25 14:55:01 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA20052 for ; Mon, 25 Feb 2002 14:55:01 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA09743 for ; Mon, 25 Feb 2002 14:52:24 -0500 (EST) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id E797D67103; Mon, 25 Feb 2002 15:11:55 -0500 (EST) Date: Mon, 25 Feb 2002 14:52:23 -0500 Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Paul Hoffman / IMC , saag@mit.edu To: Chris Wysopal From: RJ Atkinson In-Reply-To: <3C7A92A7.3090705@atstake.com> Message-Id: <2F716301-2A29-11D6-A901-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Monday, February 25, 2002, at 02:38 , Chris Wysopal wrote: > But as you say there needs to be some consensus within the IETF > for it to be an IETF document of any type. It seems clear that such consensus within the IETF emphatically does NOT exist today. A better approach is to move this document to become something other than an RFC published by someone other than RFC Editor/IETF and representing whatever that publisher (or applicable community for that publisher) thinks is appropriate. Ran From tytso@thunk.org Mon Feb 25 15:08:58 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA20318 for ; Mon, 25 Feb 2002 15:08:58 -0500 (EST) Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA00105; Mon, 25 Feb 2002 15:08:57 -0500 (EST) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.34 #1 (Debian)) id 16fRQW-00050y-00; Mon, 25 Feb 2002 15:08:48 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16fRQW-0000Ub-00; Mon, 25 Feb 2002 15:08:48 -0500 Date: Mon, 25 Feb 2002 15:08:47 -0500 From: Theodore Tso To: "D. Clyde Williamson" Cc: "Hallam-Baker, Phillip" , saag@mit.edu Subject: Re: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Message-ID: <20020225150847.B1701@thunk.org> References: <2F3EC696EAEED311BB2D009027C3F4F405869971@vhqpostal.verisign.com> <1014663831.10764.105.camel@jabberwock> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <1014663831.10764.105.camel@jabberwock>; from cwilliamson@limited.com on Mon, Feb 25, 2002 at 02:03:43PM -0500 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Mon, Feb 25, 2002 at 02:03:43PM -0500, D. Clyde Williamson wrote: > This is just silly. If I find an insecure online banking system, > shopping cart, whatever... I'm not simply going to say "Well, its none > of my business and walk away. THAT is irresponsible. If I do alert the > company and they decide to ignore me... it would be irresponsible to > leave the poor end users at the mercy of the company. Agreed. Regardless of whether not the person who discovered that E*Trade was inadequately obscuring the login password when transmogrifying it to a HTTP cookie had or hadn't a business relationship with E*Trade is completely irrelevant. As someone who has a large sum of money entrusted with E*Trade, I am very, very, very, grateful that he (a) discovered the problem, and (b) attempted to contact E*Trade, and (c) decided to take the story public after E*Trade apparently stonewalled him. So as an E*Trade customer, I don't care whether he was a concerned E*Trade customer (which Phillip Hallam-Baker seems to claim is the only people who should be allowed to ask such questions), or a researcher looking for fame and glory. My gratitude to him for finding this absolutely brain-damaged security bug is the same regardless of his motive for finding the problem. Certainly, it seemed from what happened that E*Trade couldn't be bothered to go looking for such vulnerabilities, even when it was pointed out to them explicitly. So from a public policy standpoint, it is very useful to have people who are willing to go around looking for the obvious idiocies. There's one other benefit of such public spankings; the vendors may not like it, but ultimately it benefits them in the following way: If this sort of vulnerability had been discovered by a black hat who made off with several million dollars worth of their customers' money, their customers might have simply decided that Internet-based brockerages / banking is simply too risky, and stop doing business with them entirely. - Ted From pbaker@verisign.com Mon Feb 25 15:33:22 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA20818 for ; Mon, 25 Feb 2002 15:33:22 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA16318 for ; Mon, 25 Feb 2002 15:33:21 -0500 (EST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g1PKTlR28537; Mon, 25 Feb 2002 12:29:47 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <15Y11WJG>; Mon, 25 Feb 2002 12:34:25 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869973@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'D. Clyde Williamson'" , "Hallam-Baker, Phillip" Cc: saag@mit.edu Subject: RE: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Date: Mon, 25 Feb 2002 12:34:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BE3B.C63981D0" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BE3B.C63981D0 Content-Type: text/plain; charset="iso-8859-1" > Ohhh, trying to tell journalists what is and is not the correct way to > report issues? Methinks, they could easily yell the First and say that > in reality, the purpose of the document was to cover up security flaws > that the public should know about. > > Big yuchhy mess. The publication of the Institute for Historical Review are legal under the first ammendment, but that does not make them justifiable as scholarly works. Journalists spend plenty of their time navel gazing and accusing others of ethical lapses. > Well, if this is the case... I'll run a banking site, never bother to > secure it properly, and make sure I never ask any security experts to > look at it. If you were a customer of such a bank you might have an issue. What am hearing about is 'security consultants' who claim to have identitified a security issue and offer not to tell the press about it if they are paid a large 'consulting fee'. > This is just silly. If I find an insecure online banking system, > shopping cart, whatever... I'm not simply going to say "Well, its none > of my business and walk away. THAT is irresponsible. If I do alert the > company and they decide to ignore me... it would be irresponsible to > leave the poor end users at the mercy of the company. How do you know it is insecure? Quite often someone will go off to a conference and talk about a 'major security hole' in an identified service that turns out to be based on incorrect assumptions. If someone finds a shopping cart problem they can tell Visa and/or Mastercard as the representatives of the banks who underwrite the consumer loss. If you find a bank problem then tell the secret service. The underlying assuption that nobody ever responds to identified security issues is wrong. Ten years ago there was a real problem, there was no competent law enforcement you could depend upon for anything less than a threat to national security. Vendors were still telling customers inanities such as 'you do not want shadow passwords, they are security through obscurity and a security risk'. > There is a proper and imporper way to deal with security issues. > However, I believe that the proper/improper way is different for each > situation. It depends on too many variables to try to document out the > "One Best Way". Which is why I don't believe that a one sided description of a procedure that describes 'responsible' disclosure is appropriate. The problem of disclosure is not limited to vendors who don't respond and bug finders who act irresponsibly from lack of knowledge. Problems are also caused by people whose objectives are to boost their reputation as a security expert at all costs who will report security issues regardless of the damage caused, and even regardless of the truth of the allegations. Problems are also caused by journalists who care more about grabbing headlines than accurate reporting. Yes, there is nothing we can do to prevent yellow journalism in the security area. However we don't have to accept that as the only type on offer. When I first proposed the Web to the Clinton '92 campaign as a political information tool it was to provide a feedback loop for the media. They could print as many lies as they liked, but they could not stop people finding out they were lies. Phill ------_=_NextPart_000_01C1BE3B.C63981D0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BE3B.C63981D0-- From pbaker@verisign.com Mon Feb 25 15:57:01 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA21444 for ; Mon, 25 Feb 2002 15:57:01 -0500 (EST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA28928; Mon, 25 Feb 2002 15:57:00 -0500 (EST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA02722; Mon, 25 Feb 2002 12:47:05 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <15YDVVYL>; Mon, 25 Feb 2002 12:58:05 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869976@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Theodore Tso'" , "D. Clyde Williamson" Cc: "Hallam-Baker, Phillip" , saag@mit.edu Subject: RE: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Date: Mon, 25 Feb 2002 12:57:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BE3F.13960360" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BE3F.13960360 Content-Type: text/plain; charset="iso-8859-1" > As someone who has a large sum of money entrusted with E*Trade, I am > very, very, very, grateful that he (a) discovered the problem, and (b) > attempted to contact E*Trade, and (c) decided to take the story public > after E*Trade apparently stonewalled him. The guy could have called up the SEC which has a statutory duty to regulate brokerages and filed a complaint. If the interest is actually making stuff secure then we should be checking out the full infrastructure path, including the regulatory loop. If the regulatory loop is not working it can be fixed. I do not know the circumstances in this particular case. However I am certainly not inclined to take on trust the claim that appropriate effort was made to notify anyone. I know of cases in which a claim of notification was made which is almost certainly false. I have never had difficulty finding someone to take a security issue seriously. I have only once been told that something was fixed and later found out that it was not (and that was because the guy who made the mistake was replaced and the new folk mistook the paper I sent him proposing a fix to be the design note without checking the code). Phill ------_=_NextPart_000_01C1BE3F.13960360 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BE3F.13960360-- From cwilliamson@limited.com Mon Feb 25 16:05:16 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA21613 for ; Mon, 25 Feb 2002 16:05:15 -0500 (EST) Received: from ns1.limited.com (colsmtp.limited.com [63.72.208.21]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA23028 for ; Mon, 25 Feb 2002 16:05:15 -0500 (EST) Received: from [10.128.12.151] ([192.168.6.55]) by ns1.limited.com (Switch-2.1.1/Switch-2.1.1) with ESMTP id U1PL054706838; Mon, 25 Feb 2002 16:05:04 -0500 Subject: RE: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released From: "D. Clyde Williamson" To: "Hallam-Baker, Phillip" Cc: saag@mit.edu In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869973@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F405869973@vhqpostal.verisign.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zUt1mg2mNHw15J0/vvzt" X-Mailer: Evolution/1.0.2 Date: 25 Feb 2002 16:04:55 -0500 Message-Id: <1014671105.12405.19.camel@jabberwock> Mime-Version: 1.0 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: --=-zUt1mg2mNHw15J0/vvzt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-02-25 at 15:34, Hallam-Baker, Phillip wrote: > > Ohhh, trying to tell journalists what is and is not the correct way to > > report issues? Methinks, they could easily yell the First and say that > > in reality, the purpose of the document was to cover up security flaws > > that the public should know about. > >=20 > > Big yuchhy mess. >=20 > The publication of the Institute for Historical Review are legal under th= e > first ammendment, but that does not make them justifiable as scholarly > works. >=20 > Journalists spend plenty of their time navel gazing and accusing others o= f > ethical lapses. I'm not saying that they would be in the right... I'm simply saying that the trade rags that publish irresponsibly today will continue even if this document is an RFC/BPD/TLA. If a company says anything about it... they can cry First and go from there. Gods, you might as well try to write a document to control how the National Enquirer publishes documents. > > Well, if this is the case... I'll run a banking site, never bother to > > secure it properly, and make sure I never ask any security experts to > > look at it.=20 >=20 > If you were a customer of such a bank you might have an issue. So I should only check systems for holes if they directly affect me? Do you think that's how crackers work? Do you think they make sure that some white hat has an account before they try to crack a system? Of course not. They're gonna hit wherever they want. And hiding behind 'It doesn't affect me' is just wrong. In the end it does affect you, If OnlineBankingrUs.com is compromised and the attacker makes off with lots of money... whoever underwrote them (Visa, MC, whoever) is gonna up their charges. It's just like shoplifting, I don't do it... but in the long run it affects me. > What am hearing about is 'security consultants' who claim to have > identitified a security issue and offer not to tell the press about it if > they are paid a large 'consulting fee'. >=20 That is wrong. That is extortion. That is not gonna be impacted by this or any document. Do you think that some amoral person will read this document and become enlightened? > =20 > > This is just silly. If I find an insecure online banking system, > > shopping cart, whatever... I'm not simply going to say "Well, its none > > of my business and walk away. THAT is irresponsible. If I do alert the > > company and they decide to ignore me... it would be irresponsible to > > leave the poor end users at the mercy of the company.=20 >=20 > How do you know it is insecure?=20 Hrmmm, perhaps I find out that they're storing my account number in cleartext on a cookie... sound insecure to you? (for reference the Interhack group found this out about a bank here in Columbus http://www.interhack.net/pubs/bankone-online/ ) > Quite often someone will go off to a conference and talk about a 'major > security hole' in an identified service that turns out to be based on > incorrect assumptions.=20 Great, stupid consultant for not knowing what he was talking about. Doe shtis open anyone up to a vulnerability? No not really. More scrutinty perhaps... but that's not what we're talking about here. > If someone finds a shopping cart problem they can tell Visa and/or > Mastercard as the representatives of the banks who underwrite the consume= r > loss. If you find a bank problem then tell the secret service. >=20 But, only for banks that I use right? the rest can just get stuffed? >=20 > The underlying assuption that nobody ever responds to identified security > issues is wrong. Ten years ago there was a real problem, there was no > competent law enforcement you could depend upon for anything less than a > threat to national security. Vendors were still telling customers inaniti= es > such as 'you do not want shadow passwords, they are security through > obscurity and a security risk'. The underlying assumption is that there ARE many current examples of companies who do not respond to security issues. (See the above link, see E*Trade, see the recent vulnerability that Microsoft had, which they knew about for quite some time and neglected to aleert their customers) >=20 >=20 > > There is a proper and imporper way to deal with security issues. > > However, I believe that the proper/improper way is different for each > > situation. It depends on too many variables to try to document out the > > "One Best Way". >=20 > Which is why I don't believe that a one sided description of a procedure > that describes 'responsible' disclosure is appropriate. > > The problem of disclosure is not limited to vendors who don't respond and > bug finders who act irresponsibly from lack of knowledge. Problems are al= so > caused by people whose objectives are to boost their reputation as a > security expert at all costs who will report security issues regardless o= f > the damage caused, and even regardless of the truth of the allegations. > Problems are also caused by journalists who care more about grabbing > headlines than accurate reporting. Sure, there are bad consultants, sure there are bad reporters... a document like this isn't gonna stop them. A document like this is only gonna make it more difficult for the security community to make sure that vulnerabilities are known in a timely fashion. --=20 D. Clyde Williamson Information Security Group The Limited, Inc. "Just because you're paranoid, it doesn't mean we aren't watching you." --=-zUt1mg2mNHw15J0/vvzt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUAPHqm92JCdUlJnIZxEQJnqwCfXPhHsPPN50UeRUZ8Cs3hstn9P64AoKFZ Ygre1aWCuPJuVZo2uhRPwebq =/fFN -----END PGP SIGNATURE----- --=-zUt1mg2mNHw15J0/vvzt-- From coley@linus.mitre.org Mon Feb 25 16:07:12 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA21722 for ; Mon, 25 Feb 2002 16:07:12 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA23815 for ; Mon, 25 Feb 2002 16:07:12 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1PL7B822046 for ; Mon, 25 Feb 2002 16:07:11 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1PL7Ak07480 for ; Mon, 25 Feb 2002 16:07:10 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id QAA22982; Mon, 25 Feb 2002 16:07:09 -0500 (EST) Date: Mon, 25 Feb 2002 16:07:09 -0500 (EST) Message-Id: <200202252107.QAA22982@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: One of the reasons that Chris and I chose the IETF was because the scope of the issue is beyond "just" the security industry. Disclosure affects all vendors, reporters, and customers, especially for software that is run on the Internet (the "I" in IETF if I'm not mistaken). Another reason we chose the IETF was because there were these documents called "best current practices" that dealt with something beyond strict protocol definitions. Yet another reason was the open nature of the discussions. And finally, the IETF had the process and visibility for moving such a document forward and changing it for the better. It has been suggested that the document as written is too rigid - especially with respect to the language used, and the requirements for reporters - and it doesn't allow for a variety of scenarios that different people call best practices. It could be modified in a way that discusses the pro's and con's of different approaches. Examples: "If a vendor doesn't make themselves easily accessible to reporters, then they increase the chances of reporters publicizing the vulnerability before a fix is available" "If reporters publicize a vulnerability without working with the vendor first, then there is a chance that their analysis is incorrect. However, they will notify a small percentage of security-savvy personnel who may be able to immediately address the problem, while placing less savvy personnel at greater risk, while forcing the vendor to respond quickly in a way that may produce an incomplete or incorrect fix." "Responsible disclosure" as a phrase has been criticized as being too moralistic. An alternate phrase could be used to describe the scenarios we are outlining in the document; I mentioned "coordinated disclosure" as one possibility. However, if the document is weakened to the point where any vendor (or reporter) can do whatever they want without considering the impact on others, then it will lose its effectiveness. We could also "beef up" the policy sections by moving some of the areas of disagreement or complexity (timelines, etc.) into recommendations for the content of vendor, reporter, and customer policies. Policy publication *is* a best practice. Much of the content of this I-D is possible because others have documented their own policies - from their own angles (vendor, reporter, coordinator). I don't see a problem with restructuring the document entirely, based on all the feedback we've received, and perhaps reducing the size of it significantly (at the possible expense of introducing loopholes). It still seems reasonable to try to move some altered version of the I-D through the best current practices track. Is there an alternate organization and process through which entirely open discussions can be made on a "best practices" document of this type, and achieve the same kind of reach outside the security industry? I don't know of any, but I freely admit that I could be wrong. Pointers would be appreciated. Regards, - Steve From rja@extremenetworks.com Mon Feb 25 16:19:17 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA22001 for ; Mon, 25 Feb 2002 16:19:17 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA09707 for ; Mon, 25 Feb 2002 16:19:17 -0500 (EST) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id A50EE67103; Mon, 25 Feb 2002 16:38:44 -0500 (EST) Date: Mon, 25 Feb 2002 16:19:11 -0500 Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: saag@mit.edu To: "Steven M. Christey" From: RJ Atkinson In-Reply-To: <200202252107.QAA22982@linus.mitre.org> Message-Id: <4FB9889D-2A35-11D6-A901-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Monday, February 25, 2002, at 04:07 , Steven M. Christey wrote: > However, if the document is weakened > to the point where any vendor (or reporter) can do whatever they want > without considering the impact on others, then it will lose its > effectiveness. They can do that regardless of ANY document. Ran From pbaker@verisign.com Mon Feb 25 16:28:47 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA22177 for ; Mon, 25 Feb 2002 16:28:47 -0500 (EST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA03586 for ; Mon, 25 Feb 2002 16:28:46 -0500 (EST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA07558; Mon, 25 Feb 2002 13:18:50 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <15YDVXH4>; Mon, 25 Feb 2002 13:29:50 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869978@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'D. Clyde Williamson'" , "Hallam-Baker, Phillip" Cc: saag@mit.edu Subject: RE: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Date: Mon, 25 Feb 2002 13:29:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BE43.8240DDE0" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BE43.8240DDE0 Content-Type: text/plain; charset="iso-8859-1" > > > Well, if this is the case... I'll run a banking site, > never bother to > > > secure it properly, and make sure I never ask any > security experts to > > > look at it. > > > > If you were a customer of such a bank you might have an issue. > > So I should only check systems for holes if they directly > affect me? I think that if your first recourse in response to finding one is to give the company concerned an hour's notice then call up the national press then your objective probably isn't to increase anyone's security, either short term or long term. >Do > you think that's how crackers work? Do you think they make sure that > some white hat has an account before they try to crack a system? Of > course not. They're gonna hit wherever they want. And hiding > behind 'It doesn't affect me' is just wrong. People who engage in grandstanding are going to use the document to justify their actions unless it is more balanced and states outright that there are some cases in which disclosure becomes irresponsible, if not malice in its own right. I don't think we need any more encouragement to folk to disclose security issues, it does not appear that many folk are holding back. > In the end it does affect you, If OnlineBankingrUs.com is compromised > and the attacker makes off with lots of money... whoever > underwrote them > (Visa, MC, whoever) is gonna up their charges. It's just like > shoplifting, I don't do it... but in the long run it affects me. Perhaps what the draft should do instead is describe better means by which someone can get a company to take notice. > > What am hearing about is 'security consultants' who claim to have > > identitified a security issue and offer not to tell the > press about it if > > they are paid a large 'consulting fee'. > > That is wrong. That is extortion. That is not gonna be > impacted by this > or any document. Do you think that some amoral person will read this > document and become enlightened? No, I think they will use the document in court to try to bamboozle the jury into giving them an acquital. > Hrmmm, perhaps I find out that they're storing my account number in > cleartext on a cookie... sound insecure to you? > (for reference the Interhack group found this out about a bank here in > Columbus http://www.interhack.net/pubs/bankone-online/ ) According to the site they called BankOne and even went as far as calling up an executive. They did not advise the Federal Reserve however which as the regulatory agency for banks would be a good route for providing advice through a Non-Ingnorable Source (NIS). > > Quite often someone will go off to a conference and talk > about a 'major > > security hole' in an identified service that turns out to > be based on > > incorrect assumptions. > > Great, stupid consultant for not knowing what he was talking > about. Doe > shtis open anyone up to a vulnerability? No not really. More scrutinty > perhaps... but that's not what we're talking about here. It is a form of reputation attack against the subject. > But, only for banks that I use right? the rest can just get stuffed? Your examples were banks and brokerages. If a company provides a really important service then chances are it is regulated. And if it is not regulated then it probably should be (unless it is a Texas energy trading company selling to California). If you really get stuck then call up Tom Ridge. > "Just because you're paranoid, it doesn't mean we aren't > watching you." The funniest type of intercept you ever read is the one that goes "I sometimes wonder what they would think if they were reading all this". ------_=_NextPart_000_01C1BE43.8240DDE0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BE43.8240DDE0-- From mshore@cisco.com Mon Feb 25 16:30:24 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA22240 for ; Mon, 25 Feb 2002 16:30:23 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA04291 for ; Mon, 25 Feb 2002 16:30:23 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1PLUMt28459; Mon, 25 Feb 2002 13:30:22 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACY06017; Mon, 25 Feb 2002 13:28:34 -0800 (PST) Message-Id: <5.1.0.14.0.20020225162901.03501270@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 16:33:37 -0500 To: "Steven M. Christey" , saag@mit.edu From: Melinda Shore Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea In-Reply-To: <200202252107.QAA22982@linus.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 04:07 PM 2/25/02 -0500, Steven M. Christey wrote: >One of the reasons that Chris and I chose the IETF was because the >scope of the issue is beyond "just" the security industry. It just seems really outside of the scope of the IETF, though. It has nothing to do with protocol development and to the extent that it has any central topic beyond behavioral stuff, that topic would be implementation. Why should an organization that focuses on protocol development get involved in what happens between a manufacturer and its customers? Melinda From coley@linus.mitre.org Mon Feb 25 16:34:38 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA22345 for ; Mon, 25 Feb 2002 16:34:38 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA06904 for ; Mon, 25 Feb 2002 16:34:38 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1PLYb827523 for ; Mon, 25 Feb 2002 16:34:37 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1PLYak13207 for ; Mon, 25 Feb 2002 16:34:36 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id QAA25565; Mon, 25 Feb 2002 16:34:36 -0500 (EST) Date: Mon, 25 Feb 2002 16:34:36 -0500 (EST) Message-Id: <200202252134.QAA25565@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: RE: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >The underlying assumption is that there ARE many current examples of >companies who do not respond to security issues. Here are some hard statistics that are illustrative of the scope of the problem. I admit that they don't directly answer your question. There is little empirical analysis regarding disclosure. For those who haven't heard of the CVE project that I lead, CVE is a naming standard for vulnerabilities. For various reasons, we track whether a vendor has publicly acknowledged a specific vulnerability, where "public" is generally defined as "on the Internet" or "in the press." From December 1999 to the present day, CVE has identified 2366 different issues (note: presently there are some gaps which affect these statistics). Here is the breakdown for vendor acknowledgement: 1068 had no clear public acknowledgement, or none at all. 1283 had acknowledgement. 15 were disputed by the vendor. I.e., 45% of vulnerabilities that were identified in CVE have no clear public acknowledgement by the vendor. For at least 100 of the issues with no acknowledgement, the reporter who disclosed the vulnerability either said that the vendor was aware of it, or pointed to a patch for which there were no followup discussions that confirmed whether the patch was successful or not. In approximately 20 cases, the vendor may have said something very minimal like "fixed security issue" which was not enough evidence for us to be sure they were fixing the issue that *we* cared about. Note: we cannot tell when a vendor provides a fix to customers only as part of a private upgrade - that's not "public" acknowledgement (which affects security professionals who aren't customers) - but private upgrade messages are sometimes forwarded to public forums such as Bugtraq. - Steve From tytso@thunk.org Mon Feb 25 16:43:31 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA22481 for ; Mon, 25 Feb 2002 16:43:31 -0500 (EST) Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA10340; Mon, 25 Feb 2002 16:43:30 -0500 (EST) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.34 #1 (Debian)) id 16fSu8-00059t-00; Mon, 25 Feb 2002 16:43:28 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16fSu8-0000ZJ-00; Mon, 25 Feb 2002 16:43:28 -0500 Date: Mon, 25 Feb 2002 16:43:28 -0500 From: Theodore Tso To: "Hallam-Baker, Phillip" Cc: "'Theodore Tso'" , "D. Clyde Williamson" , saag@mit.edu Subject: Re: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Message-ID: <20020225164327.E1701@thunk.org> References: <2F3EC696EAEED311BB2D009027C3F4F405869976@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869976@vhqpostal.verisign.com>; from pbaker@verisign.com on Mon, Feb 25, 2002 at 12:57:46PM -0800 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Mon, Feb 25, 2002 at 12:57:46PM -0800, Hallam-Baker, Phillip wrote: > > The guy could have called up the SEC which has a statutory duty to regulate > brokerages and filed a complaint. > > If the interest is actually making stuff secure then we should be checking > out the full infrastructure path, including the regulatory loop. If the > regulatory loop is not working it can be fixed. Ah, you mean the same regulatory loop that saved investors from losing billions of dollars from the Enron scandal? Personally, I view muck-raking journalism as an invaluable check and balance, as a supplement to regulatory and auditing control points. This was true at the beginning of the previous century in discovering problems in the meat-packing plants, and I think it is just as true today. (What you're doing is I think equivalent to trying to portray the reporters who found truely scary practices in the food plants as being after it only for their own fame and glory; but that's really attacking the messenger, when it's obviously not possible to attack the message.) > I do not know the circumstances in this particular case. However I am > certainly not inclined to take on trust the claim that appropriate effort > was made to notify anyone. I know of cases in which a claim of notification > was made which is almost certainly false. Read it and weep: http://news.com.com/2100-1017-246241.html http://www.team-asylum.com/advisories/commentaries/etrade.html http://www.internetnews.com/fina-news/article/0,,5_469761,00.html .... and in this particular case, the person who found the problem did not publish the details of the hole immediately(1), but merely the fact that that he had reported the problem to E*Trade a month ago, and they had apparently done nothing for the past month to address the problem. The publication happened to BugTraq, not via a press conference, and merely described how users could avoid the problem (a: turn off Javascript, b: don't use E*Trade until the problem is fixed). Not surprisingly, it was fixed by E*Trade 3 days later, only *after* it had been publicized. (1) http://cert.uni-stuttgart.de/archive/bugtraq/2000/09/msg00408.html > I have never had difficulty finding someone to take a security issue > seriously. For open-source projects, that has been my experience. For propietary products and/or corporate web services, where the appearance of security (for marketing purposes) seems to be far more important than the actual security of the site or product, that has *NOT* been what I've seen. - Ted From ji@research.att.com Mon Feb 25 16:57:19 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA22692 for ; Mon, 25 Feb 2002 16:57:19 -0500 (EST) From: ji@research.att.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA25360 for ; Mon, 25 Feb 2002 16:57:18 -0500 (EST) Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by mail-green.research.att.com (Postfix) with ESMTP id 8ECBC1E011 for ; Mon, 25 Feb 2002 16:57:15 -0500 (EST) Received: (from ji@localhost) by amontillado.research.att.com (8.8.7/8.8.7) id QAA12652 for saag@mit.edu; Mon, 25 Feb 2002 16:57:13 -0500 (EST) Date: Mon, 25 Feb 2002 16:57:13 -0500 (EST) Message-Id: <200202252157.QAA12652@amontillado.research.att.com> To: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > From: Melinda Shore > > It just seems really outside of the scope of the IETF, though. > It has nothing to do with protocol development and to the extent > that it has any central topic beyond behavioral stuff, that topic > would be implementation. Why should an organization that > focuses on protocol development get involved in what happens between > a manufacturer and its customers? Because we are better equipped to say what is good for the network than the PR droids who would be making up the "what happens" in the absence of any guiding from our community? (Not that this has ever prevented bad things from happening) /ji -- /\ ASCII ribbon | John "JI" Ioannidis * Secure Systems Research Department \/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 * USA /\ against | "Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals" (Fritz the Cat) From mshore@cisco.com Mon Feb 25 17:07:08 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA22836 for ; Mon, 25 Feb 2002 17:07:08 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA19887 for ; Mon, 25 Feb 2002 17:07:07 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1PM76t28430; Mon, 25 Feb 2002 14:07:06 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACY07400; Mon, 25 Feb 2002 14:05:14 -0800 (PST) Message-Id: <5.1.0.14.0.20020225170525.03507030@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 17:10:11 -0500 To: ji@research.att.com, saag@mit.edu From: Melinda Shore Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea In-Reply-To: <200202252157.QAA12652@amontillado.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 04:57 PM 2/25/02 -0500, ji@research.att.com wrote: >> From: Melinda Shore >> > It just seems really outside of the scope of the IETF, though. >> It has nothing to do with protocol development and to the extent >> that it has any central topic beyond behavioral stuff, that topic >> would be implementation. Why should an organization that >> focuses on protocol development get involved in what happens between >> a manufacturer and its customers? > >Because we are better equipped to say what is good for the network >than the PR droids who would be making up the "what happens" in the absence >of any guiding from our community? That's actually not that clear to me. A minority of the people involved with the IETF are from service providers, I think, and I'll go further out on a limb and say that people who aren't involved with building stuff and making it work, either as engineers or as consumers, have a growing presence in the IETF (professional standardizers). That this needs to be done and whether or not it should be done in the IETF are two different discussions. Melinda From svh@cert.org Mon Feb 25 17:19:28 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA23010 for ; Mon, 25 Feb 2002 17:19:28 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA05754; Mon, 25 Feb 2002 17:19:27 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.65) with ESMTP id RAA10629; Mon, 25 Feb 2002 17:18:12 -0500 (EST) Received: from firstbase.blue.cert.org (firstbase.blue.cert.org [10.10.10.45]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id RAA17735; Mon, 25 Feb 2002 17:18:12 -0500 (EST) Date: Mon, 25 Feb 2002 17:18:11 -0500 Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Shawn V. Hernan" , saag@mit.edu To: tytso@mit.edu From: "Shawn V. Hernan" In-Reply-To: Message-Id: <8E1676C9-2A3D-11D6-ACFA-0050E4E0B060@cert.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Monday, February 25, 2002, at 12:25 AM, tytso@mit.edu wrote: > Even > worse, historically, it seems that since the "coordinator" primarily > gets their revenue from the vendors, Really? Like who? I can't think of a single major "coordinator" who derives their primary revenue from vendors. Shawn From svh@cert.org Mon Feb 25 17:22:14 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA23058 for ; Mon, 25 Feb 2002 17:22:14 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA07053 for ; Mon, 25 Feb 2002 17:22:14 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.65) with ESMTP id RAA10768; Mon, 25 Feb 2002 17:22:01 -0500 (EST) Received: from firstbase.blue.cert.org (firstbase.blue.cert.org [10.10.10.45]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id RAA17805; Mon, 25 Feb 2002 17:22:01 -0500 (EST) Date: Mon, 25 Feb 2002 17:22:00 -0500 Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Shawn V. Hernan" , Pekka Nikander , saag@mit.edu To: Chris Wysopal From: "Shawn V. Hernan" In-Reply-To: <3C7A6C09.1060802@atstake.com> Message-Id: <16972CE6-2A3E-11D6-ACFA-0050E4E0B060@cert.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Monday, February 25, 2002, at 11:53 AM, Chris Wysopal wrote: > Currently in the industry there IS rough consensus on the issue. I think I'd have to disagree. The whole idea of disclosure at all is not universally accepted. Shawn From pbaker@verisign.com Mon Feb 25 17:31:57 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA23184 for ; Mon, 25 Feb 2002 17:31:57 -0500 (EST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA11065; Mon, 25 Feb 2002 17:31:57 -0500 (EST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA16503; Mon, 25 Feb 2002 14:22:02 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <15YDV56Y>; Mon, 25 Feb 2002 14:33:01 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40586997A@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Theodore Tso'" , "Hallam-Baker, Phillip" Cc: "D. Clyde Williamson" , saag@mit.edu Subject: RE: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Date: Mon, 25 Feb 2002 14:32:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BE4C.57623390" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BE4C.57623390 Content-Type: text/plain; charset="iso-8859-1" > Ah, you mean the same regulatory loop that saved investors from losing > billions of dollars from the Enron scandal? Enron's energy trading was specifically exempted from regulatory oversight, and the S&L industry was deregulated immediately before they blew up. As George Sorros observed in the Alchemy of Capitalism, regulation tends to follow a cycle with a very long period (60+ years). In the 1990s he argued we were nearing the peak of the deregulation phase. The story would have much more impact if it went 'The SEC notified X who took no action' [good for front page business section NYT] or 'The SEC took no action' [good for front page NYT plus congressional hearings]. Pull in the regulatory loop and you stand to make a difference that can be important and lasting. If you don't you will spend all your time chasing gnats with a flyswatter. > Personally, I view muck-raking journalism as an invaluable check and > balance, as a supplement to regulatory and auditing control points. > This was true at the beginning of the previous century in discovering > problems in the meat-packing plants, and I think it is just as true > today. (What you're doing is I think equivalent to trying to portray > the reporters who found truely scary practices in the food plants as > being after it only for their own fame and glory; but that's really > attacking the messenger, when it's obviously not possible to attack > the message.) Reporters generally go to talk to reputable scientists before they publish stories about meat packing plants. Or face meat libel actions in the state of Enron. Depite the apparently large number of security consultants who guarantee to return journalists calls within 30 minutes, quite a lot of security scare stories based on the allegation of the security hack alone. On the specific attack, when will people learn that anyone who ships a browser that supports Javascript is shipping a severely defective product with major security vulnerabilities? Phill ------_=_NextPart_000_01C1BE4C.57623390 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BE4C.57623390-- From coley@linus.mitre.org Mon Feb 25 17:52:23 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA23460 for ; Mon, 25 Feb 2002 17:52:23 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA08114 for ; Mon, 25 Feb 2002 17:52:23 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1PMqM810097 for ; Mon, 25 Feb 2002 17:52:22 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1PMqLk25157 for ; Mon, 25 Feb 2002 17:52:21 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id RAA08074; Mon, 25 Feb 2002 17:52:21 -0500 (EST) Date: Mon, 25 Feb 2002 17:52:21 -0500 (EST) Message-Id: <200202252252.RAA08074@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: Re: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Here are some of the reported facts of the E*Trade issue (as extracted from the URL's provided by Theodore Tso ), listed next to the specific recommendations of the current I-D. Approximately 20 bullets of the I-D are reflected in this single disclosure scenario. from http://news.com.com/2100-1017-246241.html: "There's really no excuse for (a cross-site scripting problem)," Baker said. "They've known about it for 9 months." The I-D recommendation allows reporters to release after 30 days if the vendor is not "acting in good faith." For whatever reason, the reporter gave the vendor much longer than the requested minimum. from http://cert.uni-stuttgart.de/archive/bugtraq/2000/09/pgp00044.pgp "E*TRADE was contacted via the email aliases security@etrade.com and webmaster@etrade.com on 21 August 2000." Vendor appears to have been accessible to reporters as described in I-D section 3.3.1 number 2, 3, and 4. Reporter attempted to contact the right people as identified in I-D section 3.3.1 numbers 1a, 3, and assumably 4. "Emails were exchanged on 21, 22, and 23 August 2000." Vendor response covered in I-D section 3.4 numbers 1, 2, and 4. Reporter apparently worked with the vendor in a timely fashion as suggested by 3.5.2 #1. "E*TRADE officials indicated that they were already aware of the security problems listed herein, but had not fixed them due to various kinds of corporate inertia." Covered by 3.6.1 #2: vendor gave a reason for delays in identifying the resolution. "At the time of this writing, the problems are still outstanding in E*TRADE production systems, and no estimated date has been mentioned for fixing them." Vendor apparently did not provide regular status updates as recommended in 3.5.1 #6. Vulnerability was not resolved within 30 days as suggested in 3.5.1 #8. Vendor did not appear to provide a patch or workaround as described in 3.6.1 #2, though one could claim that it did provide reasons for its inaction. Reporter appears to have given time extensions to the vendor as described in 3.5.2 #5. Reporter did not appear to involve a coordinator as suggested by 3.5.2 #6. Reporter appeared to recognize that a vendor might not fix a problem in 30 days, and gave the vendor a longer time to fix it (3.6.2 #1). Vendor did not appear to arrange a date for release as suggested in 3.7.1 #1. "I have written a full advisory describing the vulnerability and the exploit. This document is stored offline on a CD in a safe place. When E*TRADE repairs their systems, or on 21 February 2001, whichever comes first, the advisory will be released.: Reporter notified the vendor of the date of release. Not covered in the current I-D, but something that will be added. Reporter assigned and followed their own Grace Period (in spirit with 3.7.2 #4 and #5). Another news article includes an allegation that other similar vulnerabilities were found. If true, then the vendor did not follow the recommendations of 3.5.1 #4. I didn't analyze the reports of this situation line-by-line. However, as written, the current I-D shows that the Reporter followed best practices (or at least a certain best practice.) - Steve From mcr@sandelman.ottawa.on.ca Mon Feb 25 21:05:20 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA25681 for ; Mon, 25 Feb 2002 21:05:20 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA13249 for ; Mon, 25 Feb 2002 21:05:18 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g1Q256800278 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 25 Feb 2002 21:05:17 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g1PK82f10549 for ; Mon, 25 Feb 2002 15:08:09 -0500 (EST) Message-Id: <200202252008.g1PK82f10549@marajade.sandelman.ottawa.on.ca> To: saag@mit.edu Subject: Re: [Fwd: Re: [saag] The Responsible Disclosure draft: A Bad Idea] In-reply-to: Your message of "25 Feb 2002 13:50:15 EST." <1014663025.11162.89.camel@jabberwock> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 25 Feb 2002 15:08:00 -0500 From: Michael Richardson Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I have two questions: 1) among those that feel that the IETF should not publish this document, do you feel that a document of this nature should exist somewhere? (Just not within the IETF) 2) who else could publish it? I am thinking that some desire to publish such a document is to that journalists can see where their role is. Maybe some journalist association would like it instead? Or maybe Usenix? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From mcr@sandelman.ottawa.on.ca Mon Feb 25 21:05:34 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA25688 for ; Mon, 25 Feb 2002 21:05:34 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA02012; Mon, 25 Feb 2002 21:05:32 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g1Q256Q00278 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 25 Feb 2002 21:05:28 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g1PHxDe08923; Mon, 25 Feb 2002 12:59:16 -0500 (EST) Message-Id: <200202251759.g1PHxDe08923@marajade.sandelman.ottawa.on.ca> To: tytso@mit.edu cc: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea In-reply-to: Your message of "Mon, 25 Feb 2002 00:25:14 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 25 Feb 2002 12:59:12 -0500 From: Michael Richardson Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >>>>> "tytso" == tytso writes: tytso> I'm going to take a very different tack on this document, which is tytso> that I think it's a very bad idea, and shouldn't be published by tytso> the IETF at all. tytso> The IETF is an organization which whose primary strength is tytso> writing protocols for the purposes of ensuring interoperability, tytso> not policy documents, and writing a policy document in the style tytso> of a protocol, by using RFC-2119 MUST/SHOULD language doesn't tytso> change the fact that it isn't a protocol. It seems to me that it is a protocol. I say: "I have found a vulnerability" (TCP SYN) Vendor says: "I hear you" (TCP SYN/ACK) I say: "Thank you, I'll delay publishing" (TCP ACK) We have defined when I retransmit my initial SYN, what to do if I get an ICMP port unreachable, and the various timers that are involved. tytso> Why is do I believe it is a bad idea for the IETF to publish a tytso> policy document? First of all, it's not at all clear to me that tytso> it is a good thing to standardize a single process for dealing tytso> with security bugs (interoperability not being a major issue tytso> here), and in fact, I can think of several bad reasons for this. I think it we are concerned about interoperability here. My bug reporting process has to sync with some vendor's bug fixing process. Part of the problem is that if we do not standardize the timers, then I waste bandwidth (Cry wolf - a fix is in progress) or I get firewalled out. tytso> Secondly, it closes a debate for which there is no consensus in tytso> the community --- namely whether full, semi-full, or tytso> complete-closed disclosure is the Right Answer. Even if someone tytso> participates primarily in the semi-closed disclosure community, tytso> the fact that there are a number of people who practice FULL tytso> disclosure is extremelly useful, because it acts as a sanity check tytso> on those who practice semi-closed and closed disclosure. On this I agree. tytso> The problem with the IETF publishing a document, with the full tytso> imprimatur of RFC status, is that it may reprecussions in the real tytso> world that may not be desireable. At the minimum, it may cause tytso> people who disclosure full disclosure to be subject to lawsuits tytso> based on the fact that they had violated this particular RFC, and tytso> had therefore acted "irresponsibility". It would be absolutely tytso> disastrous if some number of federal or state legislatures used tytso> this document as model legislation which prohibited any other form tytso> of disclosure but what has been described in this document as tytso> "responsible". tytso> So imagine if you will a world where a vendor and coordinator act tytso> in bad faith --- it would be really, really, bad if the person who tytso> finds the security bug finds themselves forbidden from bypassing tytso> the vendor and coordinator due to laws or threats of lawsuits tytso> which were facilitated by the publication of this document with tytso> the IETF blessing. tytso> As a result, I don't believe the IETF should publish this tytso> document, regardless of how it might be tweaked. While it may be I hear you here. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From coley@linus.mitre.org Mon Feb 25 23:51:35 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA03562 for ; Mon, 25 Feb 2002 23:51:35 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA27718 for ; Mon, 25 Feb 2002 23:51:34 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1Q4pY812239 for ; Mon, 25 Feb 2002 23:51:34 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1Q4pXk04563 for ; Mon, 25 Feb 2002 23:51:33 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id XAA04740; Mon, 25 Feb 2002 23:51:33 -0500 (EST) Date: Mon, 25 Feb 2002 23:51:33 -0500 (EST) Message-Id: <200202260451.XAA04740@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: Re: [Fwd: Re: [saag] The Responsible Disclosure draft: A Bad Idea] Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Michael Richardson said: >I am thinking that some desire to publish such a document is to that >journalists can see where their role is. Maybe some journalist >association would like it instead? A clarification: this I-D uses the term "reporter" to mean someone who researches or discovers a vulnerability and communicates with the vendor. We're not taling about journalists. ("researcher" is sometimes a misnomer, so we avoided using that term.) >Or maybe Usenix? Many reporters work exclusively in non-Unix environments, so that audience would not necessarily be reached. - Steve From tim.polk@nist.gov Mon Feb 25 15:21:41 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA20628 for ; Mon, 25 Feb 2002 15:21:41 -0500 (EST) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA29290 for ; Mon, 25 Feb 2002 15:21:41 -0500 (EST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g1PKLekd028775 for ; Mon, 25 Feb 2002 15:21:40 -0500 (EST) Message-Id: <4.2.0.58.20020225144608.02383be0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 25 Feb 2002 15:20:28 -0500 To: saag@mit.edu From: Tim Polk Subject: Re: [saag] Algorithm Naming In-Reply-To: <5.0.0.25.1.20020115102058.00a40db0@mail.syd.fl.net.au> References: <2A043284-0882-11D6-BB86-0003934A9252@inet.org> <200201132351.g0DNpMn04510@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Folks, My apologies, but I have been out of the loop since the middle of January. As I try to clean up 6 weeks backlog of email, I came across this thread. It does not seem to have resolved itself, so I will add the information I should have provided in January... NIST does in fact register computer security objects; registered objects are assigned object identifiers in the arc "2.16.840.101.3". The program is referred to as the "Computer Security Objects Registry" and the url for the program is http://csrc.nist.gov/csor/ The program was established to support the SDNS program by assigning security labels, but is primarily used to assign OIDs for cryptographic algorithms and PKI certificate policies. (No security labels were ever assigned by NIST AFAIK.) NIST has assigned OIDs for FIPS approved or NIST-published cryptographic algorithms (e.g., AES in various modes and key sizes, as well as the "big" secure hash algorithms like SHA-256). We have also assigned OIDs for federal agencies' PKI certificate policies. However, the CSOR is probably not going to meet the IETF's needs. NIST does not currently register computer security objects submitted by organizations other than federal agencies. We have only registered cryptographic algorithms that are defined in a FIPS or other NIST publication. We don't register certificate policies from states or private enterprises. Hope this information was helpful. Thanks, Tim Polk From aleph1@securityfocus.com Tue Feb 26 04:10:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA06276 for ; Tue, 26 Feb 2002 04:10:27 -0500 (EST) From: aleph1@securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id EAA12165 for ; Tue, 26 Feb 2002 04:10:26 -0500 (EST) Received: (qmail 3268 invoked by uid 101); 26 Feb 2002 09:08:46 -0000 Date: Tue, 26 Feb 2002 02:08:46 -0700 To: "Steven M. Christey" Cc: saag@mit.edu Message-ID: <20020226090845.GC31902@securityfocus.com> References: <200202242146.QAA27108@linus.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202242146.QAA27108@linus.mitre.org> Subject: [saag] Re: I-D released: Responsible Vulnerability Disclosure Process Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: * Steven M. Christey (coley@linus.mitre.org) [020224 21:45]: > > >> 4) If a Vendor requests a Grace Period, then the Reporter SHOULD > >> follow the Grace Period before releasing details of the > >> vulnerability. > > > >Here you are injecting your bias into the process. s/SHOULD/MAY/ > > > >> 2) If the Vendor requests a Grace Period, the Coordinator SHOULD > >> follow the Grace Period and encourage the Reporter to follow the > >> Grace Period. > > > >Ditto. s/SHOULD/MAY/ > > Here, I was trying to account for the relatively new suggestion that > vendors could ask for a grace period. The pros and cons of this > suggestion have not been discussed fully, and we haven't seen this > practiced often enough to know how well it will work. If the notion > of a grace period is more commonly used, then customers can decide > whether the grace period is long enough for them. Nonetheless, this is basically a content decision disguised as procedure. I thought you were going to leave content decisions to the second document. > This is an important point, but I think that a line in the sand needs > to be drawn *somewhere*. As you and others have indicated, though, > this document is still too rigid in moving everyone down a single > path, despite the large number of "SHOULDs." I am afraid that that you have two conflicting goals that can't be reconciled. On one hand you want to define a procedure generic enough to fit most disclosure scenarios. On the other hand you want push your idea of "responsible disclosure", for some definition of "responsible". That definition of responsible is embodied by a set of artificial time limits or words like SHOULD or MUST. But those artificial limits take away from the flexibility of the process and can't even account for all possible "responsible" disclosure. I suggest you make up your mind. Do you want to document a disclosure process or do you want to push forward you idea of responsible disclosure? The later might possibly be done through the IETF. The later is a dictation of morals that is not the business of the IETF. If you choose the former I suggest you simply create a framework that is composed of the different steps and stages in the disclosure process and the different timers. Leave all steps optional and all timers blank. Then each vendor, coordinator, and reporter can fill in the blanks. You can also fill in the blanks and push for that particular idea of "responsible disclosure". Then, users can determine for *themselves* whether the vendor's, coordinator's, or reporter's disclosure policy was appropriate and responsible for the *particular* *circumstances* of some disclosed vulnerability. -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum From gaus@cisco.com Tue Feb 26 08:05:51 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA08424 for ; Tue, 26 Feb 2002 08:05:51 -0500 (EST) Received: from cisco.com (amsterdam.cisco.com [144.254.74.238]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA27070 for ; Tue, 26 Feb 2002 08:05:51 -0500 (EST) Received: from DRAJNOVI-W2K1.cisco.com (drajnovi-isdn-home.cisco.com [10.49.135.250]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA16313; Tue, 26 Feb 2002 14:05:48 +0100 (MET) Message-Id: <4.3.2.7.2.20020226120534.03e49750@amsterdam> X-Sender: drajnovi@amsterdam X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Feb 2002 13:05:52 +0000 To: saag@mit.edu From: Damir Rajnovic Subject: Re: [saag] INTERNET-DRAFT MITRE Cc: psirt@cisco.com In-Reply-To: <4.3.2.7.2.20020225104410.04359fb0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hi there, I am still reading all previous posts so forgive me if I will repeat things already covered. At 10:48 25/02/2002 -0800, Shawn V. Hernan wrote: >But what's missing from the motivation section is the implicit assumption >that disclosure in any form is a good thing at all. It is not intrinsicly >obvious that disclosing a vulnerability AT ALL is a Good Thing. I am Unfortunately, I can not give you an empirical evidence that disclosure is a Good Thing but I can offer you our rationale why we think that it is. It is about confidence. If our customer trust us that we are doing the Right Thing they will be more willing to buy our products (or, at least, less reluctant to consider buying from us). It is true that vendor with a good security record (fewer vulnerabilities) should be even more preferred than us but security is only one of components while considering a purchase. >certain that vendors fix vulnerabilities all the time that never get >disclosed to anyone. Should those vulnerabilities be disclosed too? They should. We are doing that. If the vulnerability is present our customers are in jeopardy. We do not and can not know that nobody else knows about it. For that reason we must assume that each and every vulnerability is known by someone. That person/group may decide to use it. The only way to warn our customers about the vulnerability is to publish it. >disclosure is beneficial. I would prefer a series of well-thought-out >essays and articles, backed by empirical data that will and I would be >willing to cooperate on such a venture. I'll even concede that perhaps >such a document could be presented Sounds good to me. I am willing to write one. >What does it mean to "reproduce" a vulnerability? There seems to be an >implicit assumption that an exploit for the vulnerability exists. I am Not necessary. My reading is that I must be able to see what is going on and if the report is genuine. We receive a fair number of reports that this or that is broken. Close inspection reveals that it is a configuration issue or problem with inadequate documentation or something along these lines. Also, the bug may require some weird conditions which are unknown and hard to reproduce. If we can not reproduce the problem we will have a very hard time finding what is broken. Like it or not, we have only limited resources and, if we fail to reproduce it _and_ reporter can not substantiate his claim and provide additional info, we will stop working on the report. >To make an analogy, a civil engineer does not need to "reproduce" a crack in a Not fair. There is only a few ways how one can cross a bridge. It is seldom that gravity change its orientation or people are starting to cross the river walking on the sides of a bridge. With software it is a bit more complex than your analogy. None the less, I do agree with you. I personally chased developers to fix things which were found by code inspection and without known exploits in existence. >I think 30 days is too short to expect resolution in most cases. 45 days >is pretty tough for many organizations. Very true. Depending on the circumstances even 45 may be inadequate. The reason is very simple - the existing deployed SW. I know that we need a fair amount of time to fix all IOS releases. One may say "So what, cut the number of releases", but it is not always possible. Not that we would not love to do it, it is that some customers are demanding to run old releases. Some customers have fixed "windows" when they can upgrade to a different SW release. In order for SW to be deployed it must pass some certification by a customer. This certification may take a long time. Once, the particular version of SW passes all hurdles it may be used for the next few years. In the mean time the customer will begin certification of the "new" SW release (which will become "old" when customer start deploying it). In conclusion, you can not always cut the number of different releases. Each release requires additional time for testing. One can make only so many testing/verification in parallel. Put things on the paper and hard fact will be revealed. And all this even as vendor is putting additional efforts to fix the issue. >Should all vendors be able to sponge off a few responsible vendors? What >about anti-trust issues? Are you turning all vendors into de facto >coordinators? If Vendor A notifies Vendor B about a problem, but vendor >B chooses to ignore it, will Vendor A be willing to rat out Vendor B? I >think having a coordinator involved in any multi vendor problem is valuable. Look from the practical side. Tell to a coordinator and forget about it. Don't waste time on co-ordination if you do not have to. Co-ordination may turn to be bigger issue and time drain than people can imagine. >>1) The Vendor MUST identify the fundamental nature of the flaw within the >>source code or in the design of the product ("Diagnosis"). > >Why? From many vendors' perspective, the less said about the cause of the >problem, the better. I believe there is value to the research and >educational community in knowing about the nature and frequency of the >cause of vulnerabilities, but many organizations (customers in this case) >would PREFER that their vendors be quiet about the cause of the problem. I fail to see additional benefit from publishing this info. Yes, research community might have more accurate statistics but nothing besides that. In most cases it will be a buffer overflow or troubles with pointers. Are we wiser now after this revelation? Cheers, Gaus ============== Damir Rajnovic , PSIRT Incident Manager, Cisco Systems Telephone: +44 7715 546 033 200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB ============== There is no insolvable problems. The question is can you accept the solution? From Alex.Audu@usa.alcatel.com Tue Feb 26 11:56:09 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA11213 for ; Tue, 26 Feb 2002 11:56:09 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged)) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA25633 for ; Tue, 26 Feb 2002 11:56:08 -0500 (EST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1QGtll23752; Tue, 26 Feb 2002 10:55:48 -0600 (CST) Message-ID: <3C7BBF94.EDE92E6C@usa.alcatel.com> Date: Tue, 26 Feb 2002 11:02:12 -0600 From: Alex Audu X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: ji@research.att.com, saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea References: <5.1.0.14.0.20020225170525.03507030@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Someone pointed out in an earlier post that this is, indeed, a protocol on how to handle vulnerability disclosure. The participants being humans and not machines shouldn't diminish the fact. Regards, Alex. Melinda Shore wrote: > At 04:57 PM 2/25/02 -0500, ji@research.att.com wrote: > >> From: Melinda Shore > >> > It just seems really outside of the scope of the IETF, though. > >> It has nothing to do with protocol development and to the extent > >> that it has any central topic beyond behavioral stuff, that topic > >> would be implementation. Why should an organization that > >> focuses on protocol development get involved in what happens between > >> a manufacturer and its customers? > > > >Because we are better equipped to say what is good for the network > >than the PR droids who would be making up the "what happens" in the absence > >of any guiding from our community? > > That's actually not that clear to me. A minority of the people > involved with the IETF are from service providers, I think, and > I'll go further out on a limb and say that people who aren't > involved with building stuff and making it work, either as engineers > or as consumers, have a growing presence in the IETF (professional > standardizers). > > That this needs to be done and whether or not it should be done in > the IETF are two different discussions. > > Melinda > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag From mshore@cisco.com Tue Feb 26 12:04:36 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA11381 for ; Tue, 26 Feb 2002 12:04:36 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA29271 for ; Tue, 26 Feb 2002 12:04:36 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1QH4UE00931; Tue, 26 Feb 2002 09:04:34 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACY28850; Tue, 26 Feb 2002 09:02:43 -0800 (PST) Message-Id: <5.1.0.14.0.20020226120228.00a96620@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Feb 2002 12:08:00 -0500 To: Alex Audu From: Melinda Shore Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Cc: saag@mit.edu In-Reply-To: <3C7BBF94.EDE92E6C@usa.alcatel.com> References: <5.1.0.14.0.20020225170525.03507030@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 11:02 AM 2/26/02 -0600, Alex Audu wrote: >Someone pointed out in an earlier post that this is, indeed, a protocol on how >to handle vulnerability disclosure. The participants being humans and not >machines shouldn't diminish the fact. It's not a wireline protocol. Perhaps the issue should be raised at NANOG to see if it's something that they consider to be within the scope of their organization. I strongly believe that this is outside the scope of the IETF, and given the current workload within the organization and *particularly* within the IESG, stuff that's marginally relevant at best should almost certainly be punted. Melinda From jmorris@cdt.org Tue Feb 26 12:41:49 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA11918 for ; Tue, 26 Feb 2002 12:41:49 -0500 (EST) Received: from esarhaddon.ability.net (esarhaddon.ability.net [216.3.3.68]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA14732 for ; Tue, 26 Feb 2002 12:41:48 -0500 (EST) Received: from [63.119.245.73] (73.cdt.org [63.119.245.73]) by esarhaddon.ability.net (8.11.6/8.11.6) with ESMTP id g1QHd3500884; Tue, 26 Feb 2002 12:39:03 -0500 Mime-Version: 1.0 X-Sender: john@mail.cdtmail.org Message-Id: In-Reply-To: <5.1.0.14.0.20020226120228.00a96620@localhost> References: <5.1.0.14.0.20020225170525.03507030@localhost> <5.1.0.14.0.20020226120228.00a96620@localhost> Date: Tue, 26 Feb 2002 12:41:15 -0500 To: Melinda Shore From: John Morris Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Cc: saag@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 12:08 PM -0500 2/26/02, Melinda Shore wrote: > >It's not a wireline protocol. Perhaps the issue should be >raised at NANOG to see if it's something that they consider >to be within the scope of their organization. I strongly >believe that this is outside the scope of the IETF, and given >the current workload within the organization and *particularly* >within the IESG, stuff that's marginally relevant at best >should almost certainly be punted. > I do not think a BCP would be truly outside of the IETF's scope. Designing wireline protocols is certainly a primary focus, but IETF's mission (as suggested by the admittedly subjective "Tao" document, www.ietf.org/tao.html) includes "identifying, and proposing solutions to, pressing operational and technical problems in the Internet." Certainly, security is one of IETF's areas of great expertise, and the prudent handling of security vulnerabilities strikes me an operational issue that can have a broad impact on the net. Now, perhaps there is zero chance of rough consensus on a BCP document, and if so then perhaps this effort should not go forward. But there are some proposals in the U.S. Congress that touch on security vulnerability reporting, and I have much greater confidence in the IETF's ability to address the issue in a thoughtful manner. John Morris ---------------------------------------- John B. Morris, Jr. Director, Internet Standards, Technology & Policy Project Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 (202) 637-9800 (202) 637-0968 fax jmorris@cdt.org http://www.cdt.org ---------------------------------------- From mshore@cisco.com Tue Feb 26 12:47:14 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA12009 for ; Tue, 26 Feb 2002 12:47:14 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA09284 for ; Tue, 26 Feb 2002 12:47:14 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1QHlDh06647; Tue, 26 Feb 2002 09:47:13 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACY30283; Tue, 26 Feb 2002 09:45:25 -0800 (PST) Message-Id: <5.1.0.14.0.20020226124806.00a9ece0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Feb 2002 12:50:40 -0500 To: John Morris From: Melinda Shore Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Cc: saag@mit.edu In-Reply-To: References: <5.1.0.14.0.20020226120228.00a96620@localhost> <5.1.0.14.0.20020225170525.03507030@localhost> <5.1.0.14.0.20020226120228.00a96620@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 12:41 PM 2/26/02 -0500, John Morris wrote: >I do not think a BCP would be truly outside of the IETF's scope. A BCP is not outside of the IETF's scope. I believe that developing meatspace procedures for dealing with implementation-related bugs is outside of the IETF's scope. Melinda From tytso@thunk.org Tue Feb 26 12:53:02 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA12092 for ; Tue, 26 Feb 2002 12:53:01 -0500 (EST) Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA11915; Tue, 26 Feb 2002 12:53:01 -0500 (EST) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.34 #1 (Debian)) id 16flmX-0006o8-00; Tue, 26 Feb 2002 12:52:53 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16flmX-0000Va-00; Tue, 26 Feb 2002 12:52:53 -0500 Date: Tue, 26 Feb 2002 12:52:53 -0500 From: Theodore Tso To: Melinda Shore Cc: Alex Audu , saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Message-ID: <20020226125253.A1839@thunk.org> References: <5.1.0.14.0.20020225170525.03507030@localhost> <3C7BBF94.EDE92E6C@usa.alcatel.com> <5.1.0.14.0.20020226120228.00a96620@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <5.1.0.14.0.20020226120228.00a96620@localhost>; from mshore@cisco.com on Tue, Feb 26, 2002 at 12:08:00PM -0500 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Tue, Feb 26, 2002 at 12:08:00PM -0500, Melinda Shore wrote: > It's not a wireline protocol. Perhaps the issue should be > raised at NANOG to see if it's something that they consider > to be within the scope of their organization. I strongly > believe that this is outside the scope of the IETF, and given > the current workload within the organization and *particularly* > within the IESG, stuff that's marginally relevant at best > should almost certainly be punted. The one place where it might become the IETF's business is if governments start passing laws that make it impossible for us to discuss security vulnerabilities of protocols in IETF working groups because it might violate some hastily drafted "Responsible Disclosure" law. (And if you don't think that's possible, consider what happened with the DMCA.) - Ted From pbaker@verisign.com Tue Feb 26 12:56:44 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA12176 for ; Tue, 26 Feb 2002 12:56:41 -0500 (EST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13433 for ; Tue, 26 Feb 2002 12:56:41 -0500 (EST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA00166; Tue, 26 Feb 2002 09:46:34 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <15YDW047>; Tue, 26 Feb 2002 09:57:34 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869985@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Shawn V. Hernan'" , Chris Wysopal Cc: Pekka Nikander , saag@mit.edu Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea Date: Tue, 26 Feb 2002 09:57:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BEEF.0713BDC0" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BEEF.0713BDC0 Content-Type: text/plain; charset="iso-8859-1" > On Monday, February 25, 2002, at 11:53 AM, Chris Wysopal wrote: > > > Currently in the industry there IS rough consensus on the issue. > > I think I'd have to disagree. The whole idea of disclosure at > all is not > universally accepted. I disagree for the oppositie reason, there is simply not adequate representation of the constituencies this affects. I think the 'consensus' in this community reflects a bias towards developers rather than operators. Unless the draft explicitly enumerates types of irresponsible behavior the document will do nothing more than re-inforce current dogma. It will be good for a three day slashdot discussion and nothing more. Listening to the RSA Cryptographers panel this morning, I don't think I am advocating an excentric or discredited point of view as Ted and Co are trying to imply. I find the discussion in this forum to be too biased to consider the output likely to be credible. Phill ------_=_NextPart_000_01C1BEEF.0713BDC0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BEEF.0713BDC0-- From mcr@sandelman.ottawa.on.ca Tue Feb 26 13:18:00 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA12499 for ; Tue, 26 Feb 2002 13:17:59 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA21815 for ; Tue, 26 Feb 2002 13:17:59 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g1QIHtm02070 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 26 Feb 2002 13:17:57 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g1QIHha24028 for ; Tue, 26 Feb 2002 13:17:48 -0500 (EST) Message-Id: <200202261817.g1QIHha24028@marajade.sandelman.ottawa.on.ca> To: saag@mit.edu Subject: Re: [Fwd: Re: [saag] The Responsible Disclosure draft: A Bad Idea] In-reply-to: Your message of "Mon, 25 Feb 2002 23:51:33 EST." <200202260451.XAA04740@linus.mitre.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 26 Feb 2002 13:17:43 -0500 From: Michael Richardson Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >>>>> "Steven" == Steven M Christey writes: Steven> Michael Richardson said: >> I am thinking that some desire to publish such a document is to that >> journalists can see where their role is. Maybe some journalist >> association would like it instead? Steven> A clarification: this I-D uses the term "reporter" to mean Steven> someone who researches or discovers a vulnerability and Steven> communicates with the vendor. We're not taling about Steven> journalists. ("researcher" is sometimes a misnomer, so we Steven> avoided using that term.) Yes, I realize that. But, it is the journalists that in the end have to understand the process. They have to understand the various stages, and when they can legitimately rip into a vendor! >> Or maybe Usenix? Steven> Many reporters work exclusively in non-Unix environments, so that Steven> audience would not necessarily be reached. Usenix and SAGE have been doing multi-OS conferences for some time. I agree that it would not reach as many by going through Usenix though. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From ho@alum.mit.edu Tue Feb 26 12:20:07 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA11643 for ; Tue, 26 Feb 2002 12:20:07 -0500 (EST) Received: from mgr2.xmission.com (mgr2.xmission.com [198.60.22.202]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA05862 for ; Tue, 26 Feb 2002 12:20:07 -0500 (EST) Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr2.xmission.com with esmtp (Exim 3.22 #1) id 16flGo-0007hG-00; Tue, 26 Feb 2002 10:20:06 -0700 Received: from [166.70.7.182] (helo=alum.mit.edu) by mail.xmission.com with esmtp (Exim 3.22 #1) id 16flGn-0005pu-00; Tue, 26 Feb 2002 10:20:06 -0700 Message-ID: <3C7BC393.2010608@alum.mit.edu> Date: Tue, 26 Feb 2002 10:19:15 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Steven M. Christey" CC: saag@mit.edu References: <200202260451.XAA04740@linus.mitre.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Inevitable Disclosure Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: It seems to me that the heart of the matter is just that someone has made up his mind that the world will be better off if a vulnerability is disclosed. He's willing to accept the possibility that the world would be even better off if everyone could be sure that the vendor knew about it before it was disclosed. The only issue is how to notify the vendor and make the disclosure. Whether this is responsible or not has already been decided in the discloser's mind, so it's not an issue for this discussion. However, in order to achieve the appearance of non-coercive behavior, the discloser should not negotiate the issue. The disclosure must happen within a short period of time. The IETF could develop secure protocols that allow the discloser to post his encrypted vulnerability description on a trusted public site, along with a signed receipt from the vendor. After 30 days, the trusted site will release the decryption key. The protocols determine the minimum standards for running the trusted site, the discloser-disclosure_site communication and the discloser-vendor communication. The discloser and the vendor can refer to the hash of the vulnerability in any subsequent comments or discussion on the matter. The vendor (small must) implement the signing service for receiving vulnerability reports. Hilarie Orman From mouse@Sparkle.Rodents.Montreal.QC.CA Tue Feb 26 15:07:39 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA14014 for ; Tue, 26 Feb 2002 15:07:39 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA23039 for ; Tue, 26 Feb 2002 15:07:37 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA00188; Tue, 26 Feb 2002 15:07:32 -0500 (EST) Date: Tue, 26 Feb 2002 15:07:32 -0500 (EST) From: der Mouse Message-Id: <200202262007.PAA00188@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea In-Reply-To: <3C7BBF94.EDE92E6C@usa.alcatel.com> References: <5.1.0.14.0.20020225170525.03507030@localhost> <3C7BBF94.EDE92E6C@usa.alcatel.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > Someone pointed out in an earlier post that this is, indeed, a > protocol on how to handle vulnerability disclosure. The participants > being humans and not machines shouldn't diminish the fact. It doesn't, but it does make it a great deal more arguable that it's not IETF material. There are a vast number of inter-human protocols running around, sokme of which are even codified in one way or another, none of which are suitable for IETF work. IMO, for what it may be worth, this is one of them. It may be valuable to try to codify "if your position on disclosure falls at about this point on the spectrum, here's a reocmmended procedure". I don't think it's a good idea for the IETF to try to do so. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse@Sparkle.Rodents.Montreal.QC.CA Tue Feb 26 15:08:56 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA14029 for ; Tue, 26 Feb 2002 15:08:56 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA24683 for ; Tue, 26 Feb 2002 15:08:54 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA00194; Tue, 26 Feb 2002 15:08:52 -0500 (EST) Date: Tue, 26 Feb 2002 15:08:52 -0500 (EST) From: der Mouse Message-Id: <200202262008.PAA00194@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: saag@mit.edu Subject: Re: [saag] Professional standardizers In-Reply-To: <3C7BBF94.EDE92E6C@usa.alcatel.com> References: <5.1.0.14.0.20020225170525.03507030@localhost> <3C7BBF94.EDE92E6C@usa.alcatel.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >> [...], and I'll go further out on a limb and say that people who >> aren't involved with building stuff and making it work, either as >> engineers or as consumers, have a growing presence in the IETF >> (professional standardizers). You may well be true, but I believe it should not be so. One thing the IETF does _not_ need is virgins talking about sex. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From jim@network.com Tue Feb 26 16:52:09 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA15423 for ; Tue, 26 Feb 2002 16:52:09 -0500 (EST) Received: from storage.network.com (storage.network.com [129.191.1.4]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA13624 for ; Tue, 26 Feb 2002 16:52:08 -0500 (EST) Received: from cremaster.network.com (cremaster.network.com [129.191.63.2]) by storage.network.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06124; Tue, 26 Feb 2002 15:52:13 -0600 (CST) Received: from jimsmac.network.COM (jimsmac.network.com [129.191.222.11]) by cremaster.network.com (8.9.3/8.9.3) with ESMTP id PAA04911; Tue, 26 Feb 2002 15:51:55 -0600 Received: (from hughes@localhost) by jimsmac.network.COM (8.11.6/8.11.6) id g1QFpe809583; Tue, 26 Feb 2002 09:51:40 -0600 X-Authentication-Warning: jimsguin.network.com: hughes set sender to jim@network.com using -f Subject: Re: [saag] Inevitable Disclosure From: Jim Hughes To: The Purple "Streak (Hilarie Orman)" Cc: "Steven M. Christey" , saag@mit.edu In-Reply-To: <3C7BC393.2010608@alum.mit.edu> References: <200202260451.XAA04740@linus.mitre.org> <3C7BC393.2010608@alum.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 09:51:39 -0600 Message-Id: <1014738699.2850.96.camel@jimsguin> Mime-Version: 1.0 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Any third party could create a service that publishes a PGP public key every day and divulges each private key exactly 30 days later. This service would be oblivious to the application. This takes the site out of the enforcement loop and eliminates the ability of the trusted party to succumb to inevitable pressure to not release or to release early. The second part of making sure the vendor knows is more troubling. I doubt a significant number of vendors will implement anything, and even if it is implemented, knowing that the mailbox is routinely checked is also problematic. A registered letter to the corporate responsible person (CEO) would be best, and would not involve the IETF police. jim On Tue, 2002-02-26 at 11:19, The Purple Streak (Hilarie Orman) wrote: > It seems to me that the heart of the matter is just that someone has > made up his mind that the world will be better off if a vulnerability > is disclosed. He's willing to accept the possibility that the world > would be even better off if everyone could be sure that the vendor > knew about it before it was disclosed. The only issue is how to notify > the vendor and make the disclosure. Whether this is responsible or > not has already been decided in the discloser's mind, so it's not an > issue for this discussion. > > However, in order to achieve the appearance of non-coercive behavior, > the discloser should not negotiate the issue. The disclosure must > happen within a short period of time. > > The IETF could develop secure protocols that allow the discloser to > post his encrypted vulnerability description on a trusted public > site, along with a signed receipt from the vendor. After 30 days, > the trusted site will release the decryption key. The protocols > determine the minimum standards for running the trusted site, > the discloser-disclosure_site communication and the discloser-vendor > communication. > > The discloser and the vendor can refer to the hash of the > vulnerability in any subsequent comments or discussion on the matter. > > The vendor (small must) implement the signing service for > receiving vulnerability reports. > > Hilarie Orman > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag -- From mcgrew@cisco.com Tue Feb 26 18:03:08 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA16263 for ; Tue, 26 Feb 2002 18:03:04 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA12238 for ; Tue, 26 Feb 2002 18:02:53 -0500 (EST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1QN2Zt20890; Tue, 26 Feb 2002 15:02:35 -0800 (PST) Received: from MCGREWW2K ([10.34.251.98]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAX35398; Tue, 26 Feb 2002 14:58:10 -0800 (PST) From: "David A. Mcgrew" To: "Vincenzo Liguori" Cc: Date: Tue, 26 Feb 2002 15:00:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Subject: [saag] RE: AES Counter Mode Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Vincenzo, > -----Original Message----- > From: Vincenzo Liguori [mailto:enzo@ocean-logic.com] > Sent: Friday, February 01, 2002 9:45 PM > To: mcgrew@cisco.com > Cc: saag@mit.edu > Subject: AES Counter Mode > > > Dear Mr. McGrew, > > My name is Vincenzo Liguori and I am the director of > Ocean logic Pty Ltd, a small company that offers soft > core IPs for VLSI implementation. > > Recently, a customer of ours has made some enquiries > regarding AES Counter Mode and we might to be add this > mode to our AES core family. > > After a short search with Google, I have found your > specification on line : > http://www.ietf.org/internet-drafts/draft-mcgrew-saag-icm-00.txt > > My questions are: > Is the draft likely to change before approval ? yes, it is likely to change, see below. Also, the draft is an individual submission, not a working group output. My goal with this draft was to create a single counter mode spec that could be used across multiple IETF crypto protocols. I included counter mode as the default cipher for secure rtp, and the icm draft conforms to that definition. At present, the consensus on counter mode (among my srtp coauthors and other that commented on that draft) are that the 128-bit addition that is required on a per-segment basis by icm is unnecessary and is costlier than we'd like. The srtp spec will probably be amended slightly by replacing that operation with XOR, then adding the condition that the lowest 16 bits of the salt value are zero. This means that the 'next counter' function is still 'plus one mod 2^128', but it changes the definition of how the initial value of the counter is established. > When is approval likely to be given ? It's not really up for approval. It's out for comments, and I'd be happy to hear yours. If there is sufficient interest in a cross-application counter mode spec, then I'll ask about making it an RFC. ICM can be viewed as a specialization of the NIST suggested CTR mode (NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation - Methods and Techniques, online at http://csrc.nist.gov/publications/nistpubs/index.html) to packet encryption. The NIST document describes a counter mode using 128-bit integer increment as the next-counter operation, while icm describes how to use that definition to generate keystream segments appropriate for packet encryption. The most important security fact about counter mode is that it should be used with a random initial counter. So no matter what spec you end up implementing, please keep that in mind :-) > Is there any reference C code available ? There will be sometime soon, as part of the srtp reference code. dam David A. McGrew, Ph.D. Manager, Strategic Crypto Development IOS Technologies Division Cisco Systems, Inc. (301) 349 5815 > > Thank you very much in advance. > > Regards, > > Vincenzo Liguori > > ------------------------------------------------------------------ > Vincenzo Liguori > Ocean Logic Pty Ltd > PO BOX 768 > Manly NSW 1655 > Australia > > Ph : +61-2-99054152 > Fax : +61-2-99050921 > Email : enzo@ocean-logic.com > WWW : http://www.ocean-logic.com > > From smb@research.att.com Tue Feb 26 18:51:47 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA16781 for ; Tue, 26 Feb 2002 18:51:47 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA19513 for ; Tue, 26 Feb 2002 18:51:47 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id C3EBB4CE12; Tue, 26 Feb 2002 18:51:46 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id SAA22051; Tue, 26 Feb 2002 18:47:52 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id C54527B4B; Tue, 26 Feb 2002 18:51:39 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "David A. Mcgrew" Cc: "Vincenzo Liguori" , saag@mit.edu Subject: Re: [saag] RE: AES Counter Mode Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Feb 2002 18:51:39 -0500 Message-Id: <20020226235139.C54527B4B@berkshire.research.att.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: In message , "David A. Mcgrew" w rites: > >The most important security fact about counter mode is that it should be >used with a random initial counter. So no matter what spec you end up >implementing, please keep that in mind :-) > Yes, that's rather important... As many folks know, I'm not a fan of counter mode. See http://www.research.att.com/~smb/papers/internet-modes.ps (or .pdf) for complete details, but the short-form answer is (a) it has very bad failure modes, and (b) any form of encryption, *especially* counter mode, needs strong authentication, and we don't know how to do that fast enough to make counter mode practical for very high-speed use. I would very much prefer one of the combined modes, as soon as NIST picks one and clears up the patent entanglements. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From the.map@alum.mit.edu Tue Feb 26 16:27:02 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA15094 for ; Tue, 26 Feb 2002 16:27:02 -0500 (EST) Received: from zoon.lafn.org (zoon.lafn.org [206.117.18.9]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA26449 for ; Tue, 26 Feb 2002 16:24:45 -0500 (EST) Received: from mike.alum.mit.edu (66-81-20-26-modem.o1.com [66.81.20.26]) by zoon.lafn.org (8.11.3/8.11.3) with ESMTP id g1QLNR374125; Tue, 26 Feb 2002 13:23:28 -0800 (PST) (envelope-from the.map@alum.mit.edu) Message-Id: <5.0.2.1.1.20020226120844.020ad640@mail.lafn.org> X-Sender: ba213@mail.lafn.org X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 26 Feb 2002 13:24:19 -0800 To: Michael Richardson , saag@mit.edu From: Mike Padlipsky Subject: Re: [Fwd: Re: [saag] The Responsible Disclosure draft: A Bad Idea] In-Reply-To: <200202252008.g1PK82f10549@marajade.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 12:08 PM 2/25/02, Michael Richardson asked: >1) among those that feel that the IETF should not publish this > document, do you feel that a document of this nature should > exist somewhere? (Just not within the IETF) > > 2) who else could publish it? 1) oh, i suppose. but only because i've managed to subordinate my personal preferences to some vague notion of 1st amendment prinicples' imperatives, so i'd be delighted to see a case made that 'free speech' notions shouldn't really be applied to a document the subtext of wh/ quite clearly seems to be: don't bother to try to 'name and shame' microsoft; the best you can hope for is to be smothered in verbiage. 2) microsoft. and/or the 'responsible disclosure forum' they've instigated, if various public press reports can be believed. after all, if it weren't for the context [and doesn't anybody else out there bother to read yahoodailynews's 'tech' stuff?], the subtext wouldn'tve been quite so clear, so why shouldn't the real beneficiary of the exercise bear the burden. but it shouldn't be given any appearance of officiality/odor of sanctity by a supposedly objective, more or less deliberative body. in fairness, perhaps some of the to-me extremely evident initial pro-vendor deckstacking has been shuffled away in response to the saag-list comments; i can't be bothered to waste still more time and bandwidth on looking at whatever the latest version is. it still seems abundantly clear to me, however, that if the ietf were a traditional legislative body, no version should be reported out of the saag 'subcommitte'; if by some parliamentary chicanery it were reported out, 'the house' should vote it down; and if by some mass hysteria it were to be accepted at that level, the 'senate' [remember the iab?] should never let it get thru 'conference'. [you can make all those 'should's 'SHOULD's, if you like.] not that i'd be willing to come out of retirement to lead the 'filibuster' even if my wristsnfingers were up to it, but even from retirement i can still tell that calling the thing a bad idea is actually too kind and/or too polite, just as i can still tell an egg is rotten w/out eating it all [and can still usually tell by the shell]: false analogies about 'it's a protocol' to the contrary notwithstanding [and i must confess i thought that was an 'emoticon'less joke when i first saw it], i submit that the appropriate analogy [well, ok, metaphor] is that it's a pit the ietf should be careful not to fall into. [and you can make that 'a cesspit', if you like.] cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] From tytso@thunk.org Wed Feb 27 03:43:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id DAA22197 for ; Wed, 27 Feb 2002 03:43:18 -0500 (EST) Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id DAA15291; Wed, 27 Feb 2002 03:43:17 -0500 (EST) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.34 #1 (Debian)) id 16fzfg-0007y5-00; Wed, 27 Feb 2002 03:42:44 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16fzfg-0001Ab-00; Wed, 27 Feb 2002 03:42:44 -0500 Date: Wed, 27 Feb 2002 03:42:44 -0500 From: Theodore Tso To: "Hallam-Baker, Phillip" Cc: "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Message-ID: <20020227034244.H1839@thunk.org> References: <2F3EC696EAEED311BB2D009027C3F4F405869985@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869985@vhqpostal.verisign.com>; from pbaker@verisign.com on Tue, Feb 26, 2002 at 09:57:16AM -0800 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Tue, Feb 26, 2002 at 09:57:16AM -0800, Hallam-Baker, Phillip wrote: > > I disagree for the oppositie reason, there is simply not adequate > representation of the constituencies this affects. > > I think the 'consensus' in this community reflects a bias towards > developers rather than operators. > Well, I think the 'consensus' in various industry forums that you and others have cited reflects a bias towards vendors who are desperate to keep their mistakes kept secret for as long as possible... Which perhaps is one way of saying we don't really have concensus after all. There are a large number of stakeholders, each with their own agenda, and trying to keep them all happy is difficult, especially when it's clear that there is a lot of distrust from many sides about whether the other folks are dealing in good faith. I for example, have listed the reasons why I'm not comfortable with a process which always assumes that vendors will act for the greater good of the community. On the other hand, you seem to think that most reporters are willing to lie and cheat and steal in order to achieve fame and glory, so you want a process which is architected to prevent the abuses which you have perceived in the system. Making a process which is both fair AND robust against all forms intentional misbehavior, AND works dispite mutual distrust on all sides, is certainly not an easy task. Some might say that it is well-nigh impossible. At the very least, I hope this means that we as a community will think very hard before we blithely take a document that purports to describe the only way that "responsible disclosure" can be done, and slap the label "Best Current Practice" on it. - Ted P.S. I'd trust vendors more if they didn't disclaim all liability for any bugs (security and otherwise) in their product --- "we warrant that this software contains ones and zeros".... Would you be willing to drive a car where the manufacturer refused to stand behind the product, and essentially said, "if this product kills your entire family, it's your problem. If we're feeling generous, maybe we'll refund the pro-rated value of your car?" If not, why are people willing to bet their businesses and their customers' money on commercial web servers that essentially have the same level of assurance? From mcgrew@cisco.com Wed Feb 27 10:34:08 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA26383 for ; Wed, 27 Feb 2002 10:34:08 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA21644 for ; Wed, 27 Feb 2002 10:34:07 -0500 (EST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1RFY7h23652; Wed, 27 Feb 2002 07:34:07 -0800 (PST) Received: from MCGREWW2K ([10.34.251.98]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAX47843; Wed, 27 Feb 2002 07:29:43 -0800 (PST) From: "David A. Mcgrew" To: "Steven M. Bellovin" Cc: "Vincenzo Liguori" , Subject: RE: [saag] RE: AES Counter Mode Date: Wed, 27 Feb 2002 07:31:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020226235139.C54527B4B@berkshire.research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steve, > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Tuesday, February 26, 2002 3:52 PM > To: David A. Mcgrew > Cc: Vincenzo Liguori; saag@mit.edu > Subject: Re: [saag] RE: AES Counter Mode > > > In message , > "David A. Mcgrew" w > rites: > > > >The most important security fact about counter mode is that it should be > >used with a random initial counter. So no matter what spec you end up > >implementing, please keep that in mind :-) > > > > Yes, that's rather important... > > As many folks know, I'm not a fan of counter mode. See > http://www.research.att.com/~smb/papers/internet-modes.ps (or .pdf) for > complete details, but the short-form answer is (a) it has very bad > failure modes, yes, CM can fail spectacularly if the same key is used multiple times. More on this below. > and (b) any form of encryption, *especially* counter > mode, needs strong authentication, and we don't know how to do that > fast enough to make counter mode practical for very high-speed use. Agreed, high-speed authentication is necessary to take advantage of high-speed CM. Actually, I have been working towards this goal, and have a specification of a universal hash function based authentication method (an adaptation of Halevi and Krawczyk's HMMH function). It's specified in http://search.ietf.org/internet-drafts/draft-mcgrew-saag-tmmh-01.txt This hash can provide strong security in the multi-gigabit per second range on commodity processors, and is inherently parallelizable. (FWIW, I'm currently extending the definition so that larger messages can be authenticated without requiring long keys.) I've also submitted a draft describing how TMMH can be used efficiently in combination with a segmented keystream generator like AES CM, in http://search.ietf.org/internet-drafts/draft-mcgrew-saag-ust-00.txt I would highly value your comments on these drafts. > I > would very much prefer one of the combined modes, as soon as NIST picks > one and clears up the patent entanglements. Off topic: is NIST still considering alternate modes? My understanding was that the recent NIST special publication on modes represents a terminus rather than a waystation. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com I think that we agree about the seriousness of the potential failures of counter mode in Section 4 of the paper that you and Matt presented at the modes workshop. My main concern is the possibility of duplicate key use during manual keying, which makes the one-time pad into a two-time pad. This concern is valid for any mode which doesn't expand the ciphertext, including CBC with implicit IV and any general-purpose stream cipher. Packet encryption using modes like CBC which explicitly include a random IV in each packet avoid this problem, but then suffer bandwidth degradation and need to generate per-packet random data. So there's a general tension between the benefits and drawbacks of explicitly including per-packet random data. Systems with automated key management, for which the duplicate key problem is not a concern, can take advantage of the benefits. It would be good to come up with requirements language that would protect implementers from the duplicate key problem. I agree with your point that manual keying of CM and similar systems should be prohibited (though IMO it would be nice to describe workarounds). What else would you recommend? thanks, dam David A. McGrew, Ph.D. Manager, Strategic Crypto Development IOS Technologies Division Cisco Systems, Inc. (301) 349 5815 From OgleR@thmulti.com Wed Feb 27 10:36:48 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA26449 for ; Wed, 27 Feb 2002 10:36:47 -0500 (EST) Received: from ns1.thmulti.com (ns1.thmulti.com [141.11.234.67]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA14104; Wed, 27 Feb 2002 10:36:37 -0500 (EST) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id QAA26929; Wed, 27 Feb 2002 16:36:23 +0100 (MET) Received: from parexch3.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id QAA05944; Wed, 27 Feb 2002 16:36:22 +0100 (MET) Received: by parexch3 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 16:36:35 +0100 Message-ID: <05B4910E0216D411B14F00508B6A67A9029419E6@RENEXCH5.rennes.thmulti.com> From: "Ogle Ron (Rennes)" To: "'Theodore Tso'" , "Hallam-Baker, Phillip" Cc: "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea Date: Wed, 27 Feb 2002 16:36:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This is why I think that before there is a "responsible disclosure" BCP document, there needs to be a "responsible vendor" BCP document. In the "responsible vendor" document, we can define different levels of responsibility that the vendor is willing to accept. This could range from "as-is" to something like "mission-critical compliant" (the idea is that the vendor is financially responsible for the correct workings of their product used correctly of course.) The "responsible disclosure" document can then apply to the different levels that the vendor is willing to accept. The less responsible the vendor the less responsible the disclosure. The theory here being that more open thought is going to be needed to find a countermeasure or work around because the vendor can't be expected to fix the problem. As vendors are more responsible (have processes in place, financially supporting these services, following best practices for software development, etc.), reporters of disclosures will have more confidence that the vendor will deal with the issues. Some how we have to tie a vendor's respect of security (in design, development, and support not just PR) to a reporter's respect of giving the vendor adequate time to solve the problem. Ron Ogle Rennes, France -----Original Message----- From: Theodore Tso [mailto:tytso@mit.edu] Sent: Wednesday, February 27, 2002 9:43 AM To: Hallam-Baker, Phillip Cc: 'Shawn V. Hernan'; Chris Wysopal; Pekka Nikander; saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea ... P.S. I'd trust vendors more if they didn't disclaim all liability for any bugs (security and otherwise) in their product --- "we warrant that this software contains ones and zeros".... Would you be willing to drive a car where the manufacturer refused to stand behind the product, and essentially said, "if this product kills your entire family, it's your problem. If we're feeling generous, maybe we'll refund the pro-rated value of your car?" If not, why are people willing to bet their businesses and their customers' money on commercial web servers that essentially have the same level of assurance? _______________________________________________ saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag From svh@cert.org Wed Feb 27 10:44:49 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA26549 for ; Wed, 27 Feb 2002 10:44:49 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA16869; Wed, 27 Feb 2002 10:44:49 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.65) with ESMTP id KAA06820; Wed, 27 Feb 2002 10:44:44 -0500 (EST) Received: from firstbase.blue.cert.org (firstbase.blue.cert.org [10.10.10.45]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id KAA09722; Wed, 27 Feb 2002 10:44:43 -0500 (EST) Date: Wed, 27 Feb 2002 10:44:42 -0500 Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Shawn V. Hernan" , "Hallam-Baker, Phillip" , Chris Wysopal , Pekka Nikander , saag@mit.edu To: Theodore Tso From: "Shawn V. Hernan" In-Reply-To: <20020227034244.H1839@thunk.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > At the very least, I hope this means that we as a community will think > very hard before we blithely take a document that purports to describe > the only way that "responsible disclosure" can be done, and slap the > label "Best Current Practice" on it. I can fully agree on this. Documents that carry the imprimatur of the IETF as a "Best Current Practice" carry some significant weight. Without empirical evidence, all we are left with is shouting. As a community, I know we're up to the challenge of collecting that evidence, forming hypotheses, and validating them. For the given draft, I think the cart is a bit before the horse. > P.S. I'd trust vendors more if they didn't disclaim all liability for > any bugs (security and otherwise) in their product --- "we warrant > that this software contains ones and zeros".... > > So would I. See for example http://www.badsoftware.com/sei.htm Shawn From pbaker@verisign.com Wed Feb 27 10:46:01 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA26603 for ; Wed, 27 Feb 2002 10:46:00 -0500 (EST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA17316; Wed, 27 Feb 2002 10:46:00 -0500 (EST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA04353; Wed, 27 Feb 2002 07:36:03 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <15YDY0CC>; Wed, 27 Feb 2002 07:47:05 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40586998F@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Theodore Tso'" , "Hallam-Baker, Phillip" Cc: "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea Date: Wed, 27 Feb 2002 07:46:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BFA5.F60498D0" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BFA5.F60498D0 Content-Type: text/plain; charset="iso-8859-1" > Well, I think the 'consensus' in various industry forums that you and > others have cited reflects a bias towards vendors who are desperate to > keep their mistakes kept secret for as long as possible... The way that you attempt to characterise this suggest to me that you simply don't accept that there can be any situation in which discretion is appropriate and that anyone who disputes your case must do so from evil motives. As your view appears to be the default here, I really don't think it is a good place to write disclosure rules. I really do not believe that the motive behind full disclosure is genuinely consequentialist. I think that the real motive for pushing full disclosure is that people think they have a right to know everything about everything and that this is internalized as an ethical system in its own right. Phill ------_=_NextPart_000_01C1BFA5.F60498D0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BFA5.F60498D0-- From rhousley@rsasecurity.com Wed Feb 27 10:54:03 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA26708 for ; Wed, 27 Feb 2002 10:54:03 -0500 (EST) Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id KAA20138 for ; Wed, 27 Feb 2002 10:54:03 -0500 (EST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) with SMTP; 27 Feb 2002 15:53:46 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA15568; Wed, 27 Feb 2002 10:53:54 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1RFs1G27642; Wed, 27 Feb 2002 10:54:01 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 10:51:52 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.53]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5M0F9; Wed, 27 Feb 2002 10:51:46 -0500 From: "Housley, Russ" To: "David A. Mcgrew" Cc: Vincenzo Liguori , saag@mit.edu Message-Id: <5.1.0.14.2.20020227103958.02fbaeb8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 10:44:24 -0500 Subject: Re: [saag] RE: AES Counter Mode In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: IEEE 802.11 is considering AES OCB and a combination of AES CTR with AES CBC-MAC for the long term solution to WEP. AES OCB presently has patent entanglements that Steve referred to. The alternative has not patent issues. Whichever one of these modes is selected by the IEEE 802.11 WG, then I think it would be very desirable for IPsec and Wireless LAN to employ the same mode. This allows chip vendors to develop a high-speed, robust solution for at least two applications. Volume always improves the price. Russ From pbaker@verisign.com Wed Feb 27 10:55:19 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA26757 for ; Wed, 27 Feb 2002 10:55:18 -0500 (EST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA20639; Wed, 27 Feb 2002 10:55:18 -0500 (EST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA05759; Wed, 27 Feb 2002 07:44:41 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <15YDY0SV>; Wed, 27 Feb 2002 07:55:43 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869990@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Ogle Ron (Rennes)'" , "'Theodore Tso'" , "Hallam-Baker, Phillip" Cc: "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea Date: Wed, 27 Feb 2002 07:55:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BFA7.29C38E50" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BFA7.29C38E50 Content-Type: text/plain; charset="iso-8859-1" I think that Ron has hit upon a good suggestion. The whole thesis underlying full disclosure is that it leads to modification of vendor behavior. We have much more direct means available to affect vendor behavior. Perhaps we could modify the CERT process to report the number of security issues outstanding against a given vendor. Vendors would then be ranked empirically by the speed with which security issues were fixed. This would also fix the current bias introduced that suggests that the least popular O/S are most secure because they have least reports, I have not seen an Open Genera alert for some time but I doubt that means it is secure (and yes you can still buy it!). The problem here is that there are a lot of security issues where there is genuine dispute over the extent to which a risk is a threat. For example almost every email security package expects the user to know that a subject line is going to be sent unencrypted. This is pointed out every couple of months and the IETF has done diddly-squat about it (except talk, we are very good at that). The excuse is then given that this is a 'user education issue'. Perhaps we should try some beam removal before disclosing other's motes. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Ogle Ron (Rennes) [mailto:OgleR@thmulti.com] > Sent: Wednesday, February 27, 2002 10:36 AM > To: 'Theodore Tso'; Hallam-Baker, Phillip > Cc: 'Shawn V. Hernan'; Chris Wysopal; Pekka Nikander; saag@mit.edu > Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea > > > This is why I think that before there is a "responsible > disclosure" BCP > document, there needs to be a "responsible vendor" BCP > document. In the > "responsible vendor" document, we can define different levels of > responsibility that the vendor is willing to accept. This > could range from > "as-is" to something like "mission-critical compliant" (the > idea is that the > vendor is financially responsible for the correct workings of > their product > used correctly of course.) > > The "responsible disclosure" document can then apply to the > different levels > that the vendor is willing to accept. The less responsible > the vendor the > less responsible the disclosure. The theory here being that more open > thought is going to be needed to find a countermeasure or work around > because the vendor can't be expected to fix the problem. As > vendors are > more responsible (have processes in place, financially > supporting these > services, following best practices for software development, etc.), > reporters of disclosures will have more confidence that the > vendor will deal > with the issues. > > Some how we have to tie a vendor's respect of security (in design, > development, and support not just PR) to a reporter's respect > of giving the > vendor adequate time to solve the problem. > > Ron Ogle > Rennes, France > > -----Original Message----- > From: Theodore Tso [mailto:tytso@mit.edu] > Sent: Wednesday, February 27, 2002 9:43 AM > To: Hallam-Baker, Phillip > Cc: 'Shawn V. Hernan'; Chris Wysopal; Pekka Nikander; saag@mit.edu > Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea > > ... > P.S. I'd trust vendors more if they didn't disclaim all liability for > any bugs (security and otherwise) in their product --- "we warrant > that this software contains ones and zeros".... > > Would you be willing to drive a car where the manufacturer refused to > stand behind the product, and essentially said, "if this product kills > your entire family, it's your problem. If we're feeling generous, > maybe we'll refund the pro-rated value of your car?" > > If not, why are people willing to bet their businesses and their > customers' money on commercial web servers that essentially have the > same level of assurance? > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > ------_=_NextPart_000_01C1BFA7.29C38E50 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BFA7.29C38E50-- From svh@cert.org Wed Feb 27 11:10:45 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA27013 for ; Wed, 27 Feb 2002 11:10:44 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08425; Wed, 27 Feb 2002 11:10:41 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.65) with ESMTP id LAA07521; Wed, 27 Feb 2002 11:10:36 -0500 (EST) Received: from firstbase.blue.cert.org (firstbase.blue.cert.org [10.10.10.45]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id LAA10464; Wed, 27 Feb 2002 11:10:36 -0500 (EST) Date: Wed, 27 Feb 2002 11:10:35 -0500 Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Shawn V. Hernan" , "'Ogle Ron (Rennes)'" , "'Theodore Tso'" , Chris Wysopal , Pekka Nikander , saag@mit.edu To: "Hallam-Baker, Phillip" From: "Shawn V. Hernan" In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869990@vhqpostal.verisign.com> Message-Id: <884294FC-2B9C-11D6-A7C9-0050E4E0B060@cert.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Wednesday, February 27, 2002, at 10:55 AM, Hallam-Baker, Phillip wrote: > Vendors would then be ranked > empirically by the speed with which security issues were fixed. Something vaguely akin to this is already available, though I don't think its exactly what you are after. (I am always interested in suggestions about additional data we should collect and publish). See, for example, http://www.kb.cert.org/vuls/id/IAFY-53NHDS http://www.kb.cert.org/vuls/id/IAFY-543RFB http://www.kb.cert.org/vuls/id/AAMN-56LQ2J These are some examples of vendor responses to issues we have notified them about. The "Date Notified" field is the earliest date for which we know the vendor knew about the issue. Shawn From aleph1@securityfocus.com Wed Feb 27 11:34:43 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA27406 for ; Wed, 27 Feb 2002 11:34:43 -0500 (EST) From: aleph1@securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id LAA19754 for ; Wed, 27 Feb 2002 11:34:43 -0500 (EST) Received: (qmail 25825 invoked by uid 101); 27 Feb 2002 16:32:49 -0000 Date: Wed, 27 Feb 2002 09:32:49 -0700 To: "Hallam-Baker, Phillip" Cc: "'Ogle Ron \(Rennes\)'" , "'Theodore Tso'" , "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Message-ID: <20020227163249.GG2418@securityfocus.com> References: <2F3EC696EAEED311BB2D009027C3F4F405869990@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869990@vhqpostal.verisign.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: * Hallam-Baker, Phillip (pbaker@verisign.com) [020227 16:06]: > I think that Ron has hit upon a good suggestion. The whole thesis underlying > full disclosure is that it leads to modification of vendor behavior. We have > much more direct means available to affect vendor behavior. False. If you knew more about the history of the full disclosure argument you would not make this mistake. The genesis of full disclosure as applied to computer system vulnerabilities was in empowering users to weight the risk to them on their own by making an informed assessment and allowing them to devise their own solutions, workarounds, and fixes. The fact that full disclosure may lead to a modification of vendor behavior is an unintended consequence. At least it was so initially. You were closer to the truth when in your last message you said: > I think that the real motive for pushing full disclosure is that > people think they have a right to know everything about everything > and that this is internalized as an ethical system in its own right. Except that they are not asking to know everything about everything. They are asking to know what the true danger is to them so that they can better defend themselves. The are many shades of full disclosure, but at its core it is a somewhat selfish philosophy. Then again so is capitalism and I don't see many here giving away their stock options. -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum From HUITEMA@windows.microsoft.com Wed Feb 27 11:45:51 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA27577 for ; Wed, 27 Feb 2002 11:45:51 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA25264; Wed, 27 Feb 2002 11:45:50 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Feb 2002 08:44:58 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Feb 2002 08:44:58 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 08:44:58 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 08:44:57 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 27 Feb 2002 08:43:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea Date: Wed, 27 Feb 2002 08:43:02 -0800 Message-ID: Thread-Topic: [saag] The Responsible Disclosure draft: A Bad Idea thread-index: AcG/clx3NRdocdlyTdOAmCHNOrhDfAAOoH3g From: "Christian Huitema" To: "Theodore Tso" , "Hallam-Baker, Phillip" Cc: "Shawn V. Hernan" , "Chris Wysopal" , "Pekka Nikander" , X-OriginalArrivalTime: 27 Feb 2002 16:43:03.0035 (UTC) FILETIME=[D2D29CB0:01C1BFAD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id LAA27577 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > > I disagree for the oppositie reason, there is simply not adequate > > representation of the constituencies this affects. > > > > I think the 'consensus' in this community reflects a bias towards > > developers rather than operators. > > > > Well, I think the 'consensus' in various industry forums that you and > others have cited reflects a bias towards vendors who are desperate to > keep their mistakes kept secret for as long as possible... Ted, There are legitimate arguments on both sides. Suppose for example that I am reviewing a piece of code and find a bug that can potentially affect millions of users. Is it more responsible to ensure that the bug is fixed so nobody suffers, or to rush to the web and make sure that the author of the bug is chastised? Then, what about the ethical considerations if the bug is actually found by a test team from the same vendor that published the code? What if I find a bug in a code I wrote, but I need at least a few weeks to test my fixes? On the other hand, the fact that there are legitimate arguments on both sides tends to reinforce your original point, that the IETF is not the proper publishing organization for this kind of documents. The IETF needs more focus on its core business, engineering Internet solutions, and this is largely a distraction. -- Christian Huitema From pbaker@verisign.com Wed Feb 27 11:59:23 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA27806 for ; Wed, 27 Feb 2002 11:59:23 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA20942; Wed, 27 Feb 2002 11:59:22 -0500 (EST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g1RGtQR24841; Wed, 27 Feb 2002 08:55:26 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <15Y1HLA2>; Wed, 27 Feb 2002 09:00:05 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869994@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'aleph1@securityfocus.com'" , "Hallam-Baker, Phillip" Cc: "'Ogle Ron (Rennes)'" , "'Theodore Tso'" , "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea Date: Wed, 27 Feb 2002 08:59:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BFB0.25C94020" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BFB0.25C94020 Content-Type: text/plain; charset="iso-8859-1" > * Hallam-Baker, Phillip (pbaker@verisign.com) [020227 16:06]: > > I think that Ron has hit upon a good suggestion. The whole > thesis underlying > > full disclosure is that it leads to modification of vendor > behavior. We have > > much more direct means available to affect vendor behavior. > > False. If you knew more about the history of the full > disclosure argument you would not make this mistake. I don't think this is the type of forum where is is advisable to get into 'I know better than you arguments'. > The genesis of full disclosure as applied to computer system > vulnerabilities was in empowering users to weight the > risk to them on their own by making an informed assessment > and allowing them to devise their own solutions, workarounds, > and fixes. Full disclosure predates Bugtraq. When the first security mailing lists began almost none of the participants had more than a minimal role in selecting computer hardware or software. The issue of 'choice' was practically non-existent. > You were closer to the truth when in your last message you said: > > > I think that the real motive for pushing full disclosure is that > > people think they have a right to know everything about everything > > and that this is internalized as an ethical system in its own right. > > Except that they are not asking to know everything about everything. > They are asking to know what the true danger is to them so > that they can better defend themselves. I think it is wanting to know for the sake of knowing. That is called science. If the motives were utilitarian the argument would be far more complex, it would be necessary to examine the circumstances of each case. Instead we have a dogmatic approach, a one size fits all attempt at a normative ethical declaration. Perhaps we should ask Peter Singer and Co to examine the question. Phill ------_=_NextPart_000_01C1BFB0.25C94020 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BFB0.25C94020-- From guninski@guninski.com Wed Feb 27 11:35:46 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA27440 for ; Wed, 27 Feb 2002 11:35:45 -0500 (EST) Received: from home.ntrl.net (home.ntrl.net [194.12.224.34]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA09691 for ; Wed, 27 Feb 2002 11:35:43 -0500 (EST) Received: from guninski.com ([194.12.248.247]) by home.ntrl.net (8.9.1/Config) with ESMTP id SAA03052 for ; Wed, 27 Feb 2002 18:35:37 +0200 Message-ID: <3C7D0B6A.1030800@guninski.com> Date: Wed, 27 Feb 2002 18:38:02 +0200 From: Georgi Guninski Reply-To: guninski@guninski.com User-Agent: Mozilla/5.0 (X11; Linux) X-Accept-Language: en-us MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Thanks, I am not buying this RFC Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Posted this to another mailing list yesterday and got advised this list is appropriate list Here are some thoughts on the so called "Responsible Vulnerability Disclosure Process" http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt This draft RFC is quite similar to seattle users's rant at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/noarch.asp It's no surprise this user Scott Culp is coauthor the draft RFC. A *very good reading* for the above topic is http://www.attrition.org/security/rant/z/ms-disclose.html written by Jericho (security curmudgeon) Anyway I disagree with at least the following from the draft RFC: 3.6.2 Reporter Responsibilities 1) The Reporter SHOULD recognize that it may be difficult for a Vendor to resolve a vulnerability within 30 days if (1) the problem is related to insecure design, (2) the Vendor has a diverse set of hardware, operating systems, and/or product versions to support, or (3) the Vendor is not skilled in security. 2) The Reporter SHOULD grant time extensions to the Vendor if the Vendor is acting in good faith to resolve the vulnerability. Here are my arguments in no particular order: *) this may allow vendors to label reporters as "RFC compliant irresponsible" while shifting the focus from their buggyware. Example: Recently Cigital disclosed a flaw in a claimed feature in microsoft's compiler. While in public forums microsoft claimed this is not a flaw but a feature, at http://news.com.com/2100-1001-838096.html the media wrote Some security experts criticized the quick public announcement as irresponsible. So the vendor denies this is any kind of bug yet to avoid negative publicity and instead the reporter is labeled "irresponsible" *) The community should encourage *disclosing* bugs even if they are fully disclosed. People with skills will always *find* bugs while they may *not disclose* them. Ever thought how many 0days are out there? And some high profile sites continue get defaced. *) I don't find it logical to be "responsible" to sell undertested and underquality software and to be "irresponsible" to disclose a bug. *) Any vendor who sells software with disclaimers which disclaim any liablity SHOULD NOT use the word responsible. *) I personally have disclosed vulnerabilities since 1996 about Oracle, IBM, Microsoft,Netscape, FreeBSD, OpenBSD, Sun and others. Only one the above has claimed I am irresponsible. Just my 2 stotinki, Georgi Guninski http://www.guninski.com From tim.polk@nist.gov Wed Feb 27 11:49:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA27661 for ; Wed, 27 Feb 2002 11:49:35 -0500 (EST) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA16273 for ; Wed, 27 Feb 2002 11:49:35 -0500 (EST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g1RGnUq6023608; Wed, 27 Feb 2002 11:49:31 -0500 (EST) Message-Id: <4.2.0.58.20020227111226.020c4630@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 27 Feb 2002 11:48:16 -0500 To: "David A. Mcgrew" , "Steven M. Bellovin" From: Tim Polk Subject: RE: [saag] RE: AES Counter Mode Cc: In-Reply-To: References: <20020226235139.C54527B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: David & Steve, At 07:31 AM 2/27/02 -0800, David A. Mcgrew wrote: > > I > > would very much prefer one of the combined modes, as soon as NIST picks > > one and clears up the patent entanglements. > >Off topic: is NIST still considering alternate modes? My understanding was >that the recent NIST special publication on modes represents a terminus >rather than a waystation. On the Off topic - The modes work is considered an ongoing process, and will be augmented with new or enhanced modes as needed. NIST is still considering additional modes for AES. The most recent modes publication is NIST SP 800-38A, and contains updated versions of the ECB, CBC, CFB, and OFB modes plus counter (CTR) mode. We expect to update SP 800-38A in 2002 to enhance CBC. In the 2002 edition of 38A the domain of the CBC mode will be extended to include plaintexts whose bit lengths are not a multiple of the block size. The next document in the series, SP 800-38B, will specify a variant of the CBC-MAC authentication mode. In an earlier message, Steve Bellovin wrote: >I would very much prefer one of the combined modes, as soon as NIST picks >one and clears up the patent entanglements. I guess this is the On topic... NIST is continuing to look at combined modes, and may recognize one in the future. This is a much more complex decision than the modes in 38A and 38B, of course. The patent entanglements alone present major challenges. Thanks, Tim Polk P.S. NIST hags a modes web page: http://csrc.nist.gov/encryption/modes/ SP 800-38A is available at http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf From kalpana_mahanta@hotmail.com Wed Feb 27 12:13:48 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA28069 for ; Wed, 27 Feb 2002 12:13:47 -0500 (EST) Received: from hotmail.com (law2-f49.hotmail.com [216.32.181.49]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA26996 for ; Wed, 27 Feb 2002 12:13:47 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Feb 2002 09:13:47 -0800 Received: from 63.78.179.5 by lw2fd.hotmail.msn.com with HTTP; Wed, 27 Feb 2002 17:13:46 GMT X-Originating-IP: [63.78.179.5] From: "Kalpana Mahanta" To: saag@mit.edu Date: Wed, 27 Feb 2002 11:13:46 -0600 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 27 Feb 2002 17:13:47.0010 (UTC) FILETIME=[1DEADE20:01C1BFB2] Subject: [saag] unsubscribe Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive:






 
--------------------------------------------------------------------------------------------------------------------------------------------
 Do more than is required.   What is the distance between someone who achieves their goals consistently and those who spend their lives and careers merely following?   The extra mile.  
-- Gary Ryan Blair
 ------------------------------------------------------------------------------------------------------------------------------------------

MSN Photos is the easiest way to share and print your photos: Click Here
From eidetic@mindspring.com Wed Feb 27 12:21:25 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA28239 for ; Wed, 27 Feb 2002 12:21:25 -0500 (EST) Received: from femail35.sdc1.sfba.home.com (femail35.sdc1.sfba.home.com [24.254.60.25]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA11343; Wed, 27 Feb 2002 12:21:24 -0500 (EST) Received: from mindspring.com ([68.13.76.121]) by femail35.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20020227172124.EFAF13229.femail35.sdc1.sfba.home.com@mindspring.com>; Wed, 27 Feb 2002 09:21:24 -0800 Message-ID: <3C7D14EC.13749FE7@mindspring.com> Date: Wed, 27 Feb 2002 11:18:36 -0600 From: Chet Uber Reply-To: eidetic@mindspring.com Organization: SecurityPosture X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'aleph1@securityfocus.com'" , "'Ogle Ron (Rennes)'" , "'Theodore Tso'" , "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea References: <2F3EC696EAEED311BB2D009027C3F4F405869994@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: et al, I have been quietly watching the traffic on this one go by, and sitting on my hands all the while. But I must add this .02: I strongly feel that pursuing a non protocol standard of such complexity, which still lacks considerable formal scientific study is outside the bounds of the IETF; and will only serve to give the impression that if you go around this "standard" (which I think people will do, as I have not heard compelling evidence that reporters would even comply) you can go around any of them. It will give a toe hold to people who want to use IETF to propagate proprietary and slightly off target (not in purview of IETF) Internet Drafts. I am probably going to get fish slapped for this, but to me this is like ICANN setting security standards as they wanted to right after 9/11. Be Well. Chet "Hallam-Baker, Phillip" wrote: > > > * Hallam-Baker, Phillip (pbaker@verisign.com) [020227 16:06]: > > > I think that Ron has hit upon a good suggestion. The whole > > thesis underlying > > > full disclosure is that it leads to modification of vendor > > behavior. We have > > > much more direct means available to affect vendor behavior. > > > > False. If you knew more about the history of the full > > disclosure argument you would not make this mistake. > > I don't think this is the type of forum where is is advisable to > get into 'I know better than you arguments'. > > > The genesis of full disclosure as applied to computer system > > vulnerabilities was in empowering users to weight the > > risk to them on their own by making an informed assessment > > and allowing them to devise their own solutions, workarounds, > > and fixes. > > Full disclosure predates Bugtraq. When the first security mailing > lists began almost none of the participants had more than a > minimal role in selecting computer hardware or software. The > issue of 'choice' was practically non-existent. > > > You were closer to the truth when in your last message you said: > > > > > I think that the real motive for pushing full disclosure is that > > > people think they have a right to know everything about everything > > > and that this is internalized as an ethical system in its own right. > > > > Except that they are not asking to know everything about everything. > > They are asking to know what the true danger is to them so > > that they can better defend themselves. > > I think it is wanting to know for the sake of knowing. That is called > science. > > If the motives were utilitarian the argument would be far more complex, > it would be necessary to examine the circumstances of each case. Instead > we have a dogmatic approach, a one size fits all attempt at a normative > ethical declaration. > > Perhaps we should ask Peter Singer and Co to examine the question. > > Phill -- Chet Uber, eidetic@mindspring.com, PGP B8DE8D3F Senior Advisor, SecurityPosture 7660 Dodge Street, Suite D - Omaha, NE 68114 vox +1 402.498.2673 fax +1 402.391.3906 cell +1 402.671.9720 -------------------------------------------------------------------------- If you are not the intended recipient be advised that you have received this email in error and any use, dissemination, forwarding, printing or copying of it is strictly prohibited. It is the responsibility of the addressee to scan this mail and any attachments for computer viruses or other defects. The sender does not accept liability for any loss or damage of any nature, however caused, which may result directly or indirectly from this email or any file attached. -------------------------------------------------------------------------- "Security First, Security Always!" (c) 2001-2002 All Rights Reserved. From mcgrew@cisco.com Wed Feb 27 12:23:17 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA28266 for ; Wed, 27 Feb 2002 12:23:17 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA12025 for ; Wed, 27 Feb 2002 12:23:16 -0500 (EST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1RHNEw29428; Wed, 27 Feb 2002 09:23:14 -0800 (PST) Received: from MCGREWW2K ([10.34.251.98]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAX49871; Wed, 27 Feb 2002 09:18:52 -0800 (PST) From: "David A. Mcgrew" To: "Tim Polk" , "Steven M. Bellovin" Cc: Subject: RE: [saag] RE: AES Counter Mode Date: Wed, 27 Feb 2002 09:21:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.2.0.58.20020227111226.020c4630@email.nist.gov> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Tim, thanks for pointing this out. More inline: > -----Original Message----- > From: Tim Polk [mailto:tim.polk@nist.gov] > Sent: Wednesday, February 27, 2002 8:48 AM > To: David A. Mcgrew; Steven M. Bellovin > Cc: saag@mit.edu > Subject: RE: [saag] RE: AES Counter Mode > > > David & Steve, > > At 07:31 AM 2/27/02 -0800, David A. Mcgrew wrote: > > > > > > I > > > would very much prefer one of the combined modes, as soon as > NIST picks > > > one and clears up the patent entanglements. > > > >Off topic: is NIST still considering alternate modes? My > understanding was > >that the recent NIST special publication on modes represents a terminus > >rather than a waystation. > > On the Off topic - > > The modes work is considered an ongoing process, and will be > augmented with > new or enhanced modes as needed. NIST is still considering additional > modes for AES. good, glad to hear that. Not sure where I picked up my misapprehension. > > The most recent modes publication is NIST SP 800-38A, and > contains updated > versions of the ECB, CBC, CFB, and OFB modes plus counter (CTR) mode. I've got to start using the conforming acronym for counter mode :-) > We > expect to update SP 800-38A in 2002 to enhance CBC. In the 2002 > edition of > 38A the domain of the CBC mode will be extended to include > plaintexts whose > bit lengths are not a multiple of the block size. Is this the residual block termination method, or something like it? thanks, David > > The next document in the series, SP 800-38B, will specify a > variant of the > CBC-MAC authentication mode. > > In an earlier message, Steve Bellovin wrote: > > > >I would very much prefer one of the combined modes, as soon as NIST picks > >one and clears up the patent entanglements. > > I guess this is the On topic... > > NIST is continuing to look at combined modes, and may recognize > one in the > future. This is a much more complex decision than the modes in 38A and > 38B, of course. The patent entanglements alone present major challenges. > > Thanks, > > Tim Polk > > P.S. NIST hags a modes web page: http://csrc.nist.gov/encryption/modes/ > SP 800-38A is available at > http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf > From tytso@thunk.org Wed Feb 27 12:29:34 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA28397 for ; Wed, 27 Feb 2002 12:29:33 -0500 (EST) Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA14852; Wed, 27 Feb 2002 12:29:33 -0500 (EST) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.34 #1 (Debian)) id 16g7tP-0000FN-00; Wed, 27 Feb 2002 12:29:27 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16g7tO-0001Vf-00; Wed, 27 Feb 2002 12:29:26 -0500 Date: Wed, 27 Feb 2002 12:29:26 -0500 From: Theodore Tso To: "Hallam-Baker, Phillip" Cc: "'Theodore Tso'" , "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu, "'Ogle Ron (Rennes)'" Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Message-ID: <20020227122926.I1839@thunk.org> References: <2F3EC696EAEED311BB2D009027C3F4F405869990@vhqpostal.verisign.com> <2F3EC696EAEED311BB2D009027C3F4F40586998F@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40586998F@vhqpostal.verisign.com>; from pbaker@verisign.com on Wed, Feb 27, 2002 at 07:46:46AM -0800 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Wed, Feb 27, 2002 at 07:46:46AM -0800, Hallam-Baker, Phillip wrote: > The way that you attempt to characterise this suggest to me > that you simply don't accept that there can be any situation > in which discretion is appropriate and that anyone who disputes > your case must do so from evil motives. Actually, no; as I said, I normally participate in a semi-closed reporting forum. I'm a member of the vendor-sec mailing list, which attempts to coordinate the disclosure of security problems amongst Linux vendors so that patches can be made available before the problems are disclosed. For that community, in general, the secrecy window is measured in days --- maybe a *very* small number of weeks in extreme cases. That is, unless the CERT is involved, in which case the vendor-sec members will honor whatever embargo period the CERT wishes to enforce (since after all that's the price of admission for getting information from that particular closed community.) In that case, sometimes then embargo period can last for a significantly longer time. The most recent example would be the SNMP vulnerabilities disclosure, which the CERT tried to keep secret **long** after it was very clear to many people it was pointless to do so. Heck, I personally witnessed the story starting to leak at the Requirements for Network Management Protocols BOF at the Salt Lake City IETF back in December, when someone mentioned in an large, open meeting that serious security problems existed in a large number of SNMP implementations, and named a few of them. Yet CERT didn't release the vulnerability until roughly the beginning of this month. So if I find a vulnerability in an open source program, I'll generally report directly to vendor-sec, and play by vendor-sec's rules --- but that's because I'm confident that vulnerabilities won't be embargoed things for months and months and months. In general, because I don't trust the CERT, even for problems that might also involve propietary vendors, I'd submit it to vendor-sec first so they, not the CERT would have the power to decide on the secrecy window. However, that's a voluntary act, and a voluntary decision, on my part. What I object to is making the semi-closed reporting scheme the only game in town, or anything which might help those who would like that to be the end-goal. That doing things any other way might land you in jail for five years or sued to the tune of tens of millions of dollars. Consider how the music and recording industry have used the DMCA to date, and I think you'll understand why I'm concerned. On Wed, Feb 27, 2002 at 07:55:22AM -0800, Hallam-Baker, Phillip wrote: > Perhaps we could modify the CERT process to report the number of security > issues outstanding against a given vendor. Vendors would then be ranked > empirically by the speed with which security issues were fixed. This would > also fix the current bias introduced that suggests that the least popular > O/S are most secure because they have least reports, I have not seen an Open > Genera alert for some time but I doubt that means it is secure (and yes you > can still buy it!). Another possibility would be immediate partial disclosure. Specifically, suppose that there was a web page which immediately discloses the vendor, the product, and the date of the report. That way, users would *know* that some kind of problem existed with, say, Microsoft IIS, and they could decide for themselves whether or not they should stop using it. The fact "some kind of problem exists" would be immediately disclosed would also act as an incentive so that vendors would put out additional information with scope of the problem, workarounds, etc., as soon as possible. Keeping tracking information about how quickly vendors respond would also be useful, but I strongly believe that users should always have a right to know that "some kind of security problem exists" for any particular product. So to take the case of the SNMP vulnerability, if it was going to take months and months and months before all the vendors would have fixes ready, maybe at the very least users should be told that filtering SNMP packets at their firewall might be a good idea, due to the fact that *some* kind of vulernability existed here. In fact, listing the vendors who were the slow-pokes that were holding up the entire disclosure from being released might also not be a bad thought. The key here is that we need to give some kind of incentive for them to move more quickly. > The problem here is that there are a lot of security issues where there is > genuine dispute over the extent to which a risk is a threat. For example > almost every email security package expects the user to know that a subject > line is going to be sent unencrypted. This is pointed out every couple of > months and the IETF has done diddly-squat about it (except talk, we are very > good at that). The excuse is then given that this is a 'user education > issue'. > > Perhaps we should try some beam removal before disclosing other's motes. Um, excuse me? We have done something about it. The IETF has standardized multiple protocols that can be used in this space --- the most recent being S/MIME and PGP. The user interface problems which you've mentioned are not protocol issues, so there isn't a lot the IETF can do about such things. I wouldn't call it a user-education issue, as much as I'd call it an "all MUA suck" issue. (My current mail reader, mutt, has as its slogan: "All mail clients suck; this one just sucks less".) Fixing this is simply outside of our scope; the IETF has never claimed that it can solve the problems of lousy MUA's or or for that matter lousy implementations of any protocol. - Ted From jesse.walker@intel.com Wed Feb 27 12:35:07 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA28501 for ; Wed, 27 Feb 2002 12:35:07 -0500 (EST) Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA06277 for ; Wed, 27 Feb 2002 12:35:06 -0500 (EST) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id RAA20180 for ; Wed, 27 Feb 2002 17:35:05 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022709403502576 ; Wed, 27 Feb 2002 09:40:35 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id <1YPLY5YC>; Wed, 27 Feb 2002 09:35:05 -0800 Message-ID: <10C8636AE359D4119118009027AE9987120B82E3@FMSMSX34> From: "Walker, Jesse" To: "David A. Mcgrew" Cc: Vincenzo Liguori , saag@mit.edu, "'Housley, Russ'" Subject: RE: [saag] RE: AES Counter Mode Date: Wed, 27 Feb 2002 09:34:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: It seems almost certain that 802.11 will select the AES-CTR mode proposal, so it would also be worthwhile to begin investing time in making the IPsec and 802.11 uses of AES-CTR compatible. -- Jesse Walker -----Original Message----- From: Housley, Russ [mailto:rhousley@rsasecurity.com] Sent: Wednesday, February 27, 2002 7:44 AM To: David A. Mcgrew Cc: Vincenzo Liguori; saag@mit.edu Subject: Re: [saag] RE: AES Counter Mode IEEE 802.11 is considering AES OCB and a combination of AES CTR with AES CBC-MAC for the long term solution to WEP. AES OCB presently has patent entanglements that Steve referred to. The alternative has not patent issues. Whichever one of these modes is selected by the IEEE 802.11 WG, then I think it would be very desirable for IPsec and Wireless LAN to employ the same mode. This allows chip vendors to develop a high-speed, robust solution for at least two applications. Volume always improves the price. Russ _______________________________________________ saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag From pbaker@verisign.com Wed Feb 27 12:46:17 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA28682 for ; Wed, 27 Feb 2002 12:46:17 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA10918; Wed, 27 Feb 2002 12:46:16 -0500 (EST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g1RHghR01829; Wed, 27 Feb 2002 09:42:43 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <15Y1HN07>; Wed, 27 Feb 2002 09:47:21 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869998@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Theodore Tso'" , "Hallam-Baker, Phillip" Cc: "'Shawn V. Hernan'" , Chris Wysopal , Pekka Nikander , saag@mit.edu, "'Ogle Ron (Rennes)'" Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea Date: Wed, 27 Feb 2002 09:46:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BFB6.BF74F1F0" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BFB6.BF74F1F0 Content-Type: text/plain; charset="iso-8859-1" > What I object to is making the semi-closed reporting scheme the only > game in town, or anything which might help those who would like that > to be the end-goal. That doing things any other way might land you in > jail for five years or sued to the tune of tens of millions of > dollars. Consider how the music and recording industry have used the > DMCA to date, and I think you'll understand why I'm concerned. I don't think there is much likelihood of that outcome. Attempting to control would simply drive people to irresponsible disclosure as the only recourse. Attempted coertion is the sure fire way to destroy everything. There was the same problem with PICS, people would only label content if they could be confident that it would not be used to support a censorship mechanism. The folk in congress went for a censorship mechanism, the whole system fell apart. > In fact, listing the vendors who were the slow-pokes that were holding > up the entire disclosure from being released might also not be a bad > thought. The key here is that we need to give some kind of incentive > for them to move more quickly. The objection there is likely to be that it gives an attacker knowledge that there is a bug there and penetration efforts are likely to be rewarded. > > Perhaps we should try some beam removal before disclosing > other's motes. > > > Um, excuse me? We have done something about it. The IETF has > standardized multiple protocols that can be used in this space --- the > most recent being S/MIME and PGP. And each time the IETF makes the same security blunder. > The user interface problems which > you've mentioned are not protocol issues, so there isn't a lot the > IETF can do about such things. Yes there is, it can recognise that security is a property of systems and put the appropriate MUSTs there. An MTA is non-compliant unless it provides the user with the right information. Or we could fix the protocols and say that if an email is encrypted the subject header of the message MUST be set to a fixed string of the user's choice e.g. ENCRYPTED. The subject line can be carried in the message body easily enough. Phill ------_=_NextPart_000_01C1BFB6.BF74F1F0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BFB6.BF74F1F0-- From mcgrew@cisco.com Wed Feb 27 14:45:04 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA00415 for ; Wed, 27 Feb 2002 14:45:03 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA13774 for ; Wed, 27 Feb 2002 14:45:02 -0500 (EST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1RJisw07293; Wed, 27 Feb 2002 11:44:54 -0800 (PST) Received: from MCGREWW2K ([10.34.251.98]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAX54224; Wed, 27 Feb 2002 11:40:31 -0800 (PST) From: "David A. Mcgrew" To: "Walker, Jesse" Cc: "Vincenzo Liguori" , , "'Housley, Russ'" Subject: RE: [saag] RE: AES Counter Mode Date: Wed, 27 Feb 2002 11:42:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <10C8636AE359D4119118009027AE9987120B82E3@FMSMSX34> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Jesse, Russ, glad to hear the interest in specifying a common interoperable CTR mode. I've talked with Doug Whiting (the other author of the 802.11 CTR work) about this, and the change to the icm draft to avoid full 128-bit addition which we adopted for srtp (that I mentioned to Vincenzo earlier) was actually his suggestion. So finding common ground across applications seems possible. If draft-mcgrew-saag-icm for the basis for this, then the outstanding issues that I see are: * replacing the per-packet 128-bit addition with xor, * agreeing on the width and alignment of fields, * generating new test vectors (half done already), * adding requirements avoiding the duplicate-key problem, strongly suggesting authentication, and possibly adding other caveats, * adding more detail about security requirements, both the theoretical results (under what usage is CTR really secure) and practical (I'd want to steal text from the now-expired stream cipher ESP for this). One option worth exploring is the possibility of adding a CTR mode option whereby per-packet random data could be included in the counter. Steve Kent's CTR proposal included something like this. dam > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Wednesday, February 27, 2002 9:35 AM > To: David A. Mcgrew > Cc: Vincenzo Liguori; saag@mit.edu; 'Housley, Russ' > Subject: RE: [saag] RE: AES Counter Mode > > > It seems almost certain that 802.11 will select the AES-CTR mode proposal, > so it would also be worthwhile to begin investing time in making the IPsec > and 802.11 uses of AES-CTR compatible. > > -- Jesse Walker > > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Wednesday, February 27, 2002 7:44 AM > To: David A. Mcgrew > Cc: Vincenzo Liguori; saag@mit.edu > Subject: Re: [saag] RE: AES Counter Mode > > > IEEE 802.11 is considering AES OCB and a combination of AES CTR with AES > CBC-MAC for the long term solution to WEP. > > AES OCB presently has patent entanglements that Steve referred to. The > alternative has not patent issues. Whichever one of these modes is > selected by the IEEE 802.11 WG, then I think it would be very > desirable for > IPsec and Wireless LAN to employ the same mode. This allows chip vendors > to develop a high-speed, robust solution for at least two > applications. Volume always improves the price. > > Russ > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag From coley@linus.mitre.org Wed Feb 27 14:49:42 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA00539 for ; Wed, 27 Feb 2002 14:49:42 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA03714 for ; Wed, 27 Feb 2002 14:49:41 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1RJne823069 for ; Wed, 27 Feb 2002 14:49:40 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1RJndk06832 for ; Wed, 27 Feb 2002 14:49:39 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id OAA14319; Wed, 27 Feb 2002 14:49:39 -0500 (EST) Date: Wed, 27 Feb 2002 14:49:39 -0500 (EST) Message-Id: <200202271949.OAA14319@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: [saag] Disclosure draft: an alternate approach Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Here is a proposal for a new version of the draft. I'm writing this in an attempt to focus the discussion that is currently taking place. First, here are the major themes that I've seen: 1) There are various approaches to disclosure that people might call "responsible." The current Internet-Draft is advocating a specific approach over others. It is clear that there cannot be IETF agreement over what is "responsible." 2) There are concerns that the document could be used by vendors to chill vulnerability reporters, especially if the document describes a single approach. 3) Based on current discussions, the disagreements about disclosure are generally based on: - how much time the reporter should give the vendor before releasing - how much detail should be provided (outside the scope of this document) - when exceptions may be made 4) Some people have questioned whether the IETF should be publishing the responsible disclosure document as a best current practice, because they do not believe that there *is* a best current practice. 5) There have been few comments on the vendor recommendations of the document besides "the requirements should be stronger." It could be that everybody is concentrating closely on the reporter; on the other hand, maybe there is a genuine chance that we can reach agreement on vendor recommendations. 6) There has been little or no disagreement with how the specific phases of disclosure have been identified or named. (There have been discussions about how some phases might be bypassed, but I haven't seen any disagreements with how the phases are laid out). 7) There has been little or no disagreement with the current draft's recommendations that reporters, vendors, and coordinators post policy statements. Some people have recommended just this. 8) There has been concern that the current draft is too long. 9) There have been disagreements with the use of MUST/SHOULD language. What would SAAG think about a new draft that made the following major changes: 1) Removal of MUST/SHOULD language. 2) Avoid the term "responsible." 3) Keep the phase names and descriptions that are currently used (latent flaw, discovery, initial notification, vendor receipt, validation, resolution, release). 4) Identify several disclosure practices that may take place, not just the one that's currently identified, and the rationales for these practices. 5) For each scenario, identify the pro's and con's of each, which phases are generally used, and discuss the considerations for timing. Allow for differences in reporter, vendor, and coordinator behaviors. 6) Preserve the recommendations for vendors to make themselves more accessible to reporters, e.g. security contact and security page (BTW, I haven't heard back from that RFC author) and receipt notification. 7) Expand the Policy Statement section for vendors, reporters, and coordinators. These recommendations would include things like timers (for vendors: how long it normally takes for receipt, validation, resolution; for reporters: how long they give a vendor before releasing), how credit is assigned, under which circumstances the party won't disclose a vulnerability (by vendors or coordinators). Basically, the "best practice" that would be recommended by the new document is better communication: (a) a "language" for describing how people do disclosure, (b) everyone can be more precise about how they act themselves, and what their expectations are of others (through the policies), and (c) there is a single document where the costs and benefits of different approaches can be made accessible to people who want to make up their own minds, which can be useful to people who are not aware of disclosure issues. The question of what is "responsible" can then be debated *outside* the IETF. What do people think? - Steve From Maureen.Stillman@nokia.com Wed Feb 27 14:52:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA00589 for ; Wed, 27 Feb 2002 14:52:27 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA17475 for ; Wed, 27 Feb 2002 14:52:27 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RJsWx26629 for ; Wed, 27 Feb 2002 13:54:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 13:52:13 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 13:51:42 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Feb 2002 13:51:42 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F81104C2B0@daebe007.NOE.Nokia.com> Thread-Topic: [saag] The Responsible Disclosure draft: A Bad Idea Thread-Index: AcG/vbeh4FAJPJTuQWuebPQcXVCudgACTuIg To: X-OriginalArrivalTime: 27 Feb 2002 19:51:42.0529 (UTC) FILETIME=[2DC45310:01C1BFC8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id OAA00589 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I agree with Melinda that this is not a wireline protocol and therefore it is out of scope (see her message below). I thought our motto was "rough consensus and running code". I'm having trouble with the "running code" part. In my opinion, this is a worthy effort, but some other group should take it on. -- maureen ----- Original Message ----- From: "Melinda Shore" To: "Alex Audu" Cc: Sent: Tuesday, February 26, 2002 12:08 PM Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea > At 11:02 AM 2/26/02 -0600, Alex Audu wrote: > >Someone pointed out in an earlier post that this is, indeed, a protocol on how > >to handle vulnerability disclosure. The participants being humans and not > >machines shouldn't diminish the fact. > > It's not a wireline protocol. Perhaps the issue should be > raised at NANOG to see if it's something that they consider > to be within the scope of their organization. I strongly > believe that this is outside the scope of the IETF, and given > the current workload within the organization and *particularly* > within the IESG, stuff that's marginally relevant at best > should almost certainly be punted. > > Melinda > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > From rhousley@rsasecurity.com Wed Feb 27 16:22:47 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA02261 for ; Wed, 27 Feb 2002 16:22:43 -0500 (EST) Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id QAA00465 for ; Wed, 27 Feb 2002 16:22:42 -0500 (EST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for FORT-POINT-STATION.MIT.EDU [18.7.7.76]) with SMTP; 27 Feb 2002 21:22:25 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA13551; Wed, 27 Feb 2002 16:22:31 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1RLMcJ29256; Wed, 27 Feb 2002 16:22:38 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 16:20:29 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NGM6; Wed, 27 Feb 2002 16:20:24 -0500 From: "Housley, Russ" To: "David A. Mcgrew" Cc: "Walker, Jesse" , Vincenzo Liguori , saag@mit.edu Message-Id: <5.1.0.14.2.20020227161931.03011dd0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 16:21:40 -0500 Subject: RE: [saag] RE: AES Counter Mode In-Reply-To: References: <10C8636AE359D4119118009027AE9987120B82E3@FMSMSX34> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: David: I am working with Doug Whiting and Niels Ferguson on the IEEE 802.11 CTR mode specification. I will be glad to share when it is stable. This should happen before the IETF meeting. The IEEE 802.11 documents are in Microsoft Word, so some conversion will be necessary before it can be posted as an Internet-Draft. Russ At 11:42 AM 2/27/2002 -0800, David A. Mcgrew wrote: >Jesse, Russ, > >glad to hear the interest in specifying a common interoperable CTR mode. >I've talked with Doug Whiting (the other author of the 802.11 CTR work) >about this, and the change to the icm draft to avoid full 128-bit addition >which we adopted for srtp (that I mentioned to Vincenzo earlier) was >actually his suggestion. So finding common ground across applications seems >possible. > >If draft-mcgrew-saag-icm for the basis for this, then the outstanding issues >that I see are: > > * replacing the per-packet 128-bit addition with xor, > > * agreeing on the width and alignment of fields, > > * generating new test vectors (half done already), > > * adding requirements avoiding the duplicate-key problem, strongly >suggesting authentication, and possibly adding other caveats, > > * adding more detail about security requirements, both the theoretical >results (under what usage is CTR really secure) and practical (I'd want to >steal text from the now-expired stream cipher ESP for this). > >One option worth exploring is the possibility of adding a CTR mode option >whereby per-packet random data could be included in the counter. Steve >Kent's CTR proposal included something like this. > >dam > > > > -----Original Message----- > > From: Walker, Jesse [mailto:jesse.walker@intel.com] > > Sent: Wednesday, February 27, 2002 9:35 AM > > To: David A. Mcgrew > > Cc: Vincenzo Liguori; saag@mit.edu; 'Housley, Russ' > > Subject: RE: [saag] RE: AES Counter Mode > > > > > > It seems almost certain that 802.11 will select the AES-CTR mode proposal, > > so it would also be worthwhile to begin investing time in making the IPsec > > and 802.11 uses of AES-CTR compatible. > > > > -- Jesse Walker > > > > -----Original Message----- > > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > > Sent: Wednesday, February 27, 2002 7:44 AM > > To: David A. Mcgrew > > Cc: Vincenzo Liguori; saag@mit.edu > > Subject: Re: [saag] RE: AES Counter Mode > > > > > > IEEE 802.11 is considering AES OCB and a combination of AES CTR with AES > > CBC-MAC for the long term solution to WEP. > > > > AES OCB presently has patent entanglements that Steve referred to. The > > alternative has not patent issues. Whichever one of these modes is > > selected by the IEEE 802.11 WG, then I think it would be very > > desirable for > > IPsec and Wireless LAN to employ the same mode. This allows chip vendors > > to develop a high-speed, robust solution for at least two > > applications. Volume always improves the price. > > > > Russ > > _______________________________________________ > > saag mailing list > > saag@mit.edu > > http://jis.mit.edu/mailman/listinfo/saag From enzo@ocean-logic.com Wed Feb 27 16:39:35 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA02504 for ; Wed, 27 Feb 2002 16:39:30 -0500 (EST) Received: from mail016.syd.optusnet.com.au (mail016.syd.optusnet.com.au [203.2.75.176]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA07984 for ; Wed, 27 Feb 2002 16:39:29 -0500 (EST) Received: from co3001263a (c40190.belrs1.nsw.optusnet.com.au [203.164.13.82]) by mail016.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id g1RLdN621815; Thu, 28 Feb 2002 08:39:23 +1100 From: "Vincenzo Liguori" To: "David A. Mcgrew" Cc: Date: Thu, 28 Feb 2002 08:39:46 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [saag] RE: AES Counter Mode Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > Vincenzo, David, thanks for your reply. > .................... > > > > My questions are: > > Is the draft likely to change before approval ? > > yes, it is likely to change, see below. Also, the draft is an individual > submission, not a working group output. My goal with this draft was to > create a single counter mode spec that could be used across multiple IETF > crypto protocols. I included counter mode as the default cipher > for secure > rtp, and the icm draft conforms to that definition. > > At present, the consensus on counter mode (among my srtp > coauthors and other > that commented on that draft) are that the 128-bit addition that > is required > on a per-segment basis by icm is unnecessary and is costlier than > we'd like. > The srtp spec will probably be amended slightly by replacing that > operation > with XOR, then adding the condition that the lowest 16 bits of the salt > value are zero. This means that the 'next counter' function is > still 'plus > one mod 2^128', but it changes the definition of how the initial value of > the counter is established. From the implementation point of view XOR is certainly less costly than an adder. > > > When is approval likely to be given ? > > It's not really up for approval. It's out for comments, and I'd > be happy to hear yours. If there is sufficient interest in a > cross-application counter mode spec, then I'll ask about making it an RFC. I'm not really a cryptography expert, my area is more image processing, but I do a lot of work in implementing algorithms in general in RTL. So, I cannot really comment of the security aspect. However, from an implementation point of view I liked that AES counter mode you proposed seems readily parallelizable and it only used AES in encryption mode. Since an encryption only AES module with a 128 bit key (with no key expander) is only about 8K gates with a max throughput of ~700 Mbit/s in 0.18 u, it follows that it would be easily possible to support multigigabit applications with a reasonable gate count. I also had a look at OCB and it was harder to implement. It also required AES in both encryption and decryption mode. I don't remember exactly, but I'm not sure whether it was readily parallelizable. > > ICM can be viewed as a specialization of the NIST suggested CTR mode (NIST > Special Publication 800-38A, Recommendation for Block Cipher Modes of > Operation - Methods and Techniques, online at > http://csrc.nist.gov/publications/nistpubs/index.html) to packet > encryption. > The NIST document describes a counter mode using 128-bit integer increment > as the next-counter operation, while icm describes how to use that > definition to generate keystream segments appropriate for packet > encryption. > > The most important security fact about counter mode is that it should be > used with a random initial counter. True random number in hardware are not too hard to generate. The problem is convincing the ASIC vendor to accept the exotic circuit that intentionally violates all their rules :-) > So no matter what spec you end up > implementing, please keep that in mind :-) I wouldn't implement something until it is standard or unless a customer asks me to. > > > Is there any reference C code available ? > > There will be sometime soon, as part of the srtp reference code. Thanks again. Is there a way to keep up to date on this ? Maybe I can join this mailing list if possible. I don't expect to contribute, but I list I can follow when consensus is reached. > > dam Enzo ------------------------------------------------------------------ Vincenzo Liguori Ocean Logic Pty Ltd PO BOX 768 Manly NSW 1655 Australia Ph : +61-2-99054152 Fax : +61-2-99050921 Email : enzo@ocean-logic.com WWW : http://www.ocean-logic.com From smb@research.att.com Wed Feb 27 17:17:36 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA03081 for ; Wed, 27 Feb 2002 17:17:36 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA22490 for ; Wed, 27 Feb 2002 17:11:58 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id A90F51E025; Wed, 27 Feb 2002 17:11:57 -0500 (EST) Received: from berkshire.research.att.com (sigaba.research.att.com [135.207.23.169]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id RAA23801; Wed, 27 Feb 2002 17:08:03 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 6FD3A7B4B; Wed, 27 Feb 2002 17:11:54 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: saag From: "Steven M. Bellovin" To: "Housley, Russ" Cc: "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@mit.edu Subject: Re: [saag] RE: AES Counter Mode Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 27 Feb 2002 17:11:54 -0500 Message-Id: <20020227221154.6FD3A7B4B@berkshire.research.att.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: In message <5.1.0.14.2.20020227161931.03011dd0@exna07.securitydynamics.com>, "H ousley, Russ" writes: >David: > >I am working with Doug Whiting and Niels Ferguson on the IEEE 802.11 CTR >mode specification. I will be glad to share when it is stable. This >should happen before the IETF meeting. The IEEE 802.11 documents are in >Microsoft Word, so some conversion will be necessary before it can be >posted as an Internet-Draft. > Why is 802.11 going with counter mode instead of CBC? That creates a strong need for some sort of random number generator, for the initial counter. (There were two great sins and one piece of bad luck in WEP. The greatest sin was in not specifying a key management protocol. The lesser (but still great) sin was in using a stream cipher -- counter mode perpetuates that. The bad luck was the cryptanalytic attack on the cipher it happened to use -- but that wasn't predictable.) From rhousley@rsasecurity.com Wed Feb 27 17:41:07 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA03398 for ; Wed, 27 Feb 2002 17:41:07 -0500 (EST) Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id RAA21933 for ; Wed, 27 Feb 2002 17:41:07 -0500 (EST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) with SMTP; 27 Feb 2002 22:40:49 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA18255; Wed, 27 Feb 2002 17:40:57 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1RMf5d04645; Wed, 27 Feb 2002 17:41:05 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 17:38:55 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.50]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NH4W; Wed, 27 Feb 2002 17:38:52 -0500 From: "Housley, Russ" To: "Steven M. Bellovin" Cc: "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@mit.edu Message-Id: <5.1.0.14.2.20020227173530.0302e0d8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 17:40:42 -0500 Subject: Re: [saag] RE: AES Counter Mode In-Reply-To: <20020227221154.6FD3A7B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steve: There is no a need for the random number in this situation. An counter (starting at zero) is sufficient. The counter block includes the source MAC address, so precomputation attacks would have to be targeted at a single traffic source. Successful precomputation attacks usually rely on the ability to find matches in the traffic from any source. When it is finished, I'll send you the paper (as well as David McGrew). Russ At 05:11 PM 2/27/2002 -0500, Steven M. Bellovin wrote: >In message ><5.1.0.14.2.20020227161931.03011dd0@exna07.securitydynamics.com>, "H >ousley, Russ" writes: > >David: > > > >I am working with Doug Whiting and Niels Ferguson on the IEEE 802.11 CTR > >mode specification. I will be glad to share when it is stable. This > >should happen before the IETF meeting. The IEEE 802.11 documents are in > >Microsoft Word, so some conversion will be necessary before it can be > >posted as an Internet-Draft. > > > >Why is 802.11 going with counter mode instead of CBC? That creates a >strong need for some sort of random number generator, for the initial >counter. (There were two great sins and one piece of bad luck in WEP. >The greatest sin was in not specifying a key management protocol. The >lesser (but still great) sin was in using a stream cipher -- counter >mode perpetuates that. The bad luck was the cryptanalytic attack on >the cipher it happened to use -- but that wasn't predictable.) There were more sins, but this is probably not the forum to discuss them. Russ From warlord@MIT.EDU Wed Feb 27 18:21:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA03933 for ; Wed, 27 Feb 2002 18:21:35 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA09250; Wed, 27 Feb 2002 18:21:27 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA24675; Wed, 27 Feb 2002 18:21:26 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA27830; Wed, 27 Feb 2002 18:21:26 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA29841; Wed, 27 Feb 2002 18:21:25 -0500 (EST) To: "Housley, Russ" Cc: "Steven M. Bellovin" , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@MIT.EDU From: Derek Atkins Subject: Re: [saag] RE: AES Counter Mode References: <5.1.0.14.2.20020227173530.0302e0d8@exna07.securitydynamics.com> Date: 27 Feb 2002 18:21:25 -0500 In-Reply-To: <5.1.0.14.2.20020227173530.0302e0d8@exna07.securitydynamics.com> Message-ID: Lines: 61 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Russ, One would think that the Access Point would be an "interesting" MAC address to try to break, and it's not like that changes very often... -derek PS: I'd be interested in the paper, too. "Housley, Russ" writes: > Steve: > > There is no a need for the random number in this situation. An > counter (starting at zero) is sufficient. The counter block includes > the source MAC address, so precomputation attacks would have to be > targeted at a single traffic source. Successful precomputation > attacks usually rely on the ability to find matches in the traffic > from any source. > > When it is finished, I'll send you the paper (as well as David McGrew). > > Russ > > At 05:11 PM 2/27/2002 -0500, Steven M. Bellovin wrote: > > In message > > <5.1.0.14.2.20020227161931.03011dd0@exna07.securitydynamics.com>, "H > >ousley, Russ" writes: > > >David: > > > > > >I am working with Doug Whiting and Niels Ferguson on the IEEE 802.11 CTR > > >mode specification. I will be glad to share when it is stable. This > > >should happen before the IETF meeting. The IEEE 802.11 documents are in > > >Microsoft Word, so some conversion will be necessary before it can be > > >posted as an Internet-Draft. > > > > > > >Why is 802.11 going with counter mode instead of CBC? That creates a > >strong need for some sort of random number generator, for the initial > >counter. (There were two great sins and one piece of bad luck in WEP. > >The greatest sin was in not specifying a key management protocol. The > >lesser (but still great) sin was in using a stream cipher -- counter > >mode perpetuates that. The bad luck was the cryptanalytic attack on > >the cipher it happened to use -- but that wasn't predictable.) > > There were more sins, but this is probably not the forum to discuss them. > > Russ > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag -- 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 mbaugher@cisco.com Wed Feb 27 18:27:21 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA04012 for ; Wed, 27 Feb 2002 18:27:21 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA22888 for ; Wed, 27 Feb 2002 18:27:20 -0500 (EST) Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1RNRIw00231; Wed, 27 Feb 2002 15:27:18 -0800 (PST) Received: from mbaugher-w2k1.cisco.com ([10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id AAZ23041; Wed, 27 Feb 2002 15:25:38 -0800 (PST) Message-Id: <4.3.2.7.2.20020227151940.047b7d20@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Feb 2002 15:24:54 -0800 To: "Housley, Russ" From: Mark Baugher Subject: Re: [saag] RE: AES Counter Mode Cc: "Steven M. Bellovin" , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@mit.edu In-Reply-To: <5.1.0.14.2.20020227173530.0302e0d8@exna07.securitydynamics .com> References: <20020227221154.6FD3A7B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Russ I am interested in this because http://csrc.nist.gov/encryption/modes/workshop1/papers/lipmaa-ctr.pdf claims that the counter can start at any known or random initial value. So I know where it's been asserted but I don't know where it's proven. Mark At 05:40 PM 2/27/2002 -0500, Housley, Russ wrote: >Steve: > >There is no a need for the random number in this situation. An counter >(starting at zero) is sufficient. The counter block includes the source >MAC address, so precomputation attacks would have to be targeted at a >single traffic source. Successful precomputation attacks usually rely on >the ability to find matches in the traffic from any source. > >When it is finished, I'll send you the paper (as well as David McGrew). > >Russ > >At 05:11 PM 2/27/2002 -0500, Steven M. Bellovin wrote: >>In message >><5.1.0.14.2.20020227161931.03011dd0@exna07.securitydynamics.com>, "H >>ousley, Russ" writes: >> >David: >> > >> >I am working with Doug Whiting and Niels Ferguson on the IEEE 802.11 CTR >> >mode specification. I will be glad to share when it is stable. This >> >should happen before the IETF meeting. The IEEE 802.11 documents are in >> >Microsoft Word, so some conversion will be necessary before it can be >> >posted as an Internet-Draft. >> > >> >>Why is 802.11 going with counter mode instead of CBC? That creates a >>strong need for some sort of random number generator, for the initial >>counter. (There were two great sins and one piece of bad luck in WEP. >>The greatest sin was in not specifying a key management protocol. The >>lesser (but still great) sin was in using a stream cipher -- counter >>mode perpetuates that. The bad luck was the cryptanalytic attack on >>the cipher it happened to use -- but that wasn't predictable.) > >There were more sins, but this is probably not the forum to discuss them. > >Russ > > >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From the.map@alum.mit.edu Thu Feb 28 01:58:23 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id BAA08942 for ; Thu, 28 Feb 2002 01:58:23 -0500 (EST) Received: from zoon.lafn.org (zoon.lafn.org [206.117.18.9]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id BAA22744 for ; Thu, 28 Feb 2002 01:58:22 -0500 (EST) Received: from mike.alum.mit.edu (66-81-19-103-modem.o1.com [66.81.19.103]) by zoon.lafn.org (8.11.3/8.11.3) with ESMTP id g1S6vpx71365; Wed, 27 Feb 2002 22:57:53 -0800 (PST) (envelope-from the.map@alum.mit.edu) Message-Id: <5.0.2.1.1.20020227172937.020ab710@mail.lafn.org> X-Sender: ba213@mail.lafn.org X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 27 Feb 2002 22:59:17 -0800 To: saag@mit.edu From: Mike Padlipsky Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [saag] the 'responsible disclosure' merry-go-round Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 11:49 AM 2/27/02, Steven M. Christey wrote: >4) Some people have questioned whether the IETF should be publishing > the responsible disclosure document as a best current practice, > because they do not believe that there *is* a best current > practice. riiiiiight. however: 4a) for also-unspecified values of some, some other people have questioned whether the ietf shld be publishing _anything_ on this topic, 'bcp'-labeled or not. 4b) still other some-value of people have expressed or implied that such a document is inescapably a weapon for the vendors, by its very nature ... and its very genesis. 4c) several [just for variety] other people have expressed distaste at seeing the topic dealt w/ on/in saag in the first place, and spkg of being able to tell by the shell at least one person was sufficiently convinced it didn't belong on/in saag that he elected to leave saag before the barrage started [... unless 'unsubscribe' has to be the subject line rather than the first contents line in the 'mailman' world, anyway]. 4d) people in classes 4, 4a, 4b, and 4c will, effectively, be ignored. [as, likely, will this be, but some windmills still demand tilting w/ and/or at, however spavined rosinante's gotten.] wld anybody get it if i bothered to point out that 4d is predictable by Ricebowl Theory? for that matter, will anybody get it if i remind everybody that At 02:30 PM 2/18/02, Jeffrey I. Schiller wrote: >Actually it was my suggestion to use the SAAG list. If indeed a >substantial discussion ensues that isn't of interest to most SAAG >subscribers, then I can setup a new mailing list for it. > > -Jeff or will that merely lead to a pious-sounding count of people in 4-4c by one or the other of the usual interested parties and a declaration that wexxxthey don't represent 'most saag subscribers'? HOW ABOUT IF PEOPLE WHO HAVE HAD ENOUGH BUT DON'T WANT TO BREAK THE OTHER GUY'S RICEBOWL IN PUBLIC JUST SEND OFF-LIST MSGS TO JEFF, THEN? SOMETHING LIKE MR. MODERATOR, TURN OFF THIS MERRY-GO-ROUND. OUGHT DO IT. [ , to save you the bother of looking it up.] granted, that encompasses a risk that the putative results of the new list's discussion will be attempted to be palmedxxxpassed off to the ietf as a favorable [metaphorical-]sub-committee report, from a potentially stacked and/or packed [metaphorical-]sub-committee, but the risk seems acceptable, given that the alternative is far too likely to be an attempt to call the putative results of further 'discussion' here the consensus of saag anyway, so in either case we'll have to hope the ietf won't fall for it, but at least that way we won't be further inundated involuntarily.... [sure, i cld unsubscribe mslf, but it's the only technical list i still bother w/ and i'm not only vaguely sentimental abt it but when i go i want it to be on my own terms, not because i've been driven off by distaste for seeing inordinate amounts of time and bandwidth wasted on what i take -- unduly influenced by reports in the public press or not -- to be Their stalking-horses.] cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] From lakan_g21@yahoo.com Thu Feb 28 08:52:00 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA13146 for ; Thu, 28 Feb 2002 08:52:00 -0500 (EST) Received: from web14808.mail.yahoo.com (web14808.mail.yahoo.com [216.136.224.224]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id IAA04931 for ; Thu, 28 Feb 2002 08:52:00 -0500 (EST) Message-ID: <20020228135159.13525.qmail@web14808.mail.yahoo.com> Received: from [203.199.209.99] by web14808.mail.yahoo.com via HTTP; Thu, 28 Feb 2002 05:51:59 PST Date: Thu, 28 Feb 2002 05:51:59 -0800 (PST) From: Lakshmanan G Subject: [saag] unsubscribe To: saag@mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com From rhousley@rsasecurity.com Thu Feb 28 09:25:07 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA13575 for ; Thu, 28 Feb 2002 09:25:07 -0500 (EST) Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id JAA16165 for ; Thu, 28 Feb 2002 09:25:06 -0500 (EST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for FORT-POINT-STATION.MIT.EDU [18.7.7.76]) with SMTP; 28 Feb 2002 14:24:48 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA14450; Thu, 28 Feb 2002 09:24:55 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1SEOwl09288; Thu, 28 Feb 2002 09:25:03 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 09:22:47 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.92]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NN4R; Thu, 28 Feb 2002 09:22:43 -0500 From: "Housley, Russ" To: Derek Atkins Cc: "Steven M. Bellovin" , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@MIT.EDU Message-Id: <5.1.0.14.2.20020228085148.0302a628@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 09:21:02 -0500 Subject: Re: [saag] RE: AES Counter Mode In-Reply-To: References: <5.1.0.14.2.20020227173530.0302e0d8@exna07.securitydynamics.com> <5.1.0.14.2.20020227173530.0302e0d8@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Derek: Yes, the access point is the obvious target; however, one access point is not likely to generate enough traffic for the precomputation attack to be successful. The front of every packet is likely to be a constant (due to RFC 1042). This is an ideal environment for precomputation attacks. By including the source MAC address in the counter block, the precomputation attack must be mounted against a single packet source. With AES using 128-bit keys, the attacker must construct a table with 2^128 entries to be completely sure that the key can be "looked up". Obviously storing and sorting a table of this size requires a heroic effort. Of course, an attacker could build a portion of the table, say 2^64 entries, and have a 50-50 chance of a "hit" in the table. This would let the attacker, on average, read half of the traffic. Storing and sorting a table of this size is still a huge effort. Remember that such a table must be constructed for each access point! The attacker must capture the packet that was encrypted with the single counter block value that was used for the precomputation. During the crypto period for a key, there will be one packet that meets this characteristic (unless the attacker has the processing power and storage capacity to store multiple tables). So each time the key is changed, the attacker will get the opportunity to capture one packet and search the table. If we were to start the counter at a random value, the attacker's situation would only be slightly more difficult. The attacker would have to watch for the counter value associated with the precomputation table. If the counter field is big enough, then the value used by the attacker might not get used with every key. The tables associated with the precomputation attacks are extremely large and unwieldy. I think it is more likely that the keys would be extracted from an implementation. The assurance of implementations needs to improve significantly before the effort associated with such a precomputation attack would even be considered by an attacker. Russ At 06:21 PM 2/27/2002 -0500, Derek Atkins wrote: >Russ, > >One would think that the Access Point would be an "interesting" >MAC address to try to break, and it's not like that changes >very often... > >-derek > >PS: I'd be interested in the paper, too. > >"Housley, Russ" writes: > > > Steve: > > > > There is no a need for the random number in this situation. An > > counter (starting at zero) is sufficient. The counter block includes > > the source MAC address, so precomputation attacks would have to be > > targeted at a single traffic source. Successful precomputation > > attacks usually rely on the ability to find matches in the traffic > > from any source. > > > > When it is finished, I'll send you the paper (as well as David McGrew). > > > > Russ > > > > At 05:11 PM 2/27/2002 -0500, Steven M. Bellovin wrote: > > > In message > > > <5.1.0.14.2.20020227161931.03011dd0@exna07.securitydynamics.com>, "H > > >ousley, Russ" writes: > > > >David: > > > > > > > >I am working with Doug Whiting and Niels Ferguson on the IEEE 802.11 CTR > > > >mode specification. I will be glad to share when it is stable. This > > > >should happen before the IETF meeting. The IEEE 802.11 documents are in > > > >Microsoft Word, so some conversion will be necessary before it can be > > > >posted as an Internet-Draft. > > > > > > > > > >Why is 802.11 going with counter mode instead of CBC? That creates a > > >strong need for some sort of random number generator, for the initial > > >counter. (There were two great sins and one piece of bad luck in WEP. > > >The greatest sin was in not specifying a key management protocol. The > > >lesser (but still great) sin was in using a stream cipher -- counter > > >mode perpetuates that. The bad luck was the cryptanalytic attack on > > >the cipher it happened to use -- but that wasn't predictable.) > > > > There were more sins, but this is probably not the forum to discuss them. > > > > Russ > > > > > > _______________________________________________ > > saag mailing list > > saag@mit.edu > > http://jis.mit.edu/mailman/listinfo/saag > >-- > 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 rblewett@csc.com Thu Feb 28 09:58:06 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA14045 for ; Thu, 28 Feb 2002 09:58:06 -0500 (EST) From: rblewett@csc.com Received: from pony-express6.csc.com (ponyexpress6.csc.com [208.219.64.206]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA10975 for ; Thu, 28 Feb 2002 09:58:06 -0500 (EST) Received: from csc.com (va-fch34.vtc.csc.com [20.1.6.97]) by pony-express6.csc.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GS900DUA09YNG@pony-express6.csc.com> for saag@mit.edu; Thu, 28 Feb 2002 09:58:46 -0500 (EST) Date: Thu, 28 Feb 2002 09:58:36 -0500 Subject: [saag] unsubscribe To: saag@mit.edu Message-id: MIME-version: 1.0 X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 5.0.8 |June 18, 2001) at 02/28/2002 10:02:08 AM Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Please remove me from your list. From mshore@cisco.com Thu Feb 28 10:01:50 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA14103 for ; Thu, 28 Feb 2002 10:01:50 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA12378 for ; Thu, 28 Feb 2002 10:01:50 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1SF1lw24776; Thu, 28 Feb 2002 07:01:47 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACZ00290; Thu, 28 Feb 2002 06:59:59 -0800 (PST) Message-Id: <5.1.0.14.0.20020228100249.00ab19a0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 10:04:15 -0500 To: "Steven M. Christey" , saag@mit.edu From: Melinda Shore Subject: Re: [saag] Disclosure draft: an alternate approach In-Reply-To: <200202271949.OAA14319@linus.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 02:49 PM 2/27/02 -0500, Steven M. Christey wrote: >4) Some people have questioned whether the IETF should be publishing > the responsible disclosure document as a best current practice, > because they do not believe that there *is* a best current > practice. I don't believe that the IETF should be publishing it because the work is outside the scope of the organization. And it's not "questioning" it - I'm quite certain that that's the case. Melinda From smb@research.att.com Thu Feb 28 10:01:05 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA14091 for ; Thu, 28 Feb 2002 10:01:02 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA12089 for ; Thu, 28 Feb 2002 10:01:01 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 692BC1E09E; Thu, 28 Feb 2002 10:00:57 -0500 (EST) Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id JAA10450; Thu, 28 Feb 2002 09:56:58 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 0BF417B4B; Thu, 28 Feb 2002 10:00:42 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Housley, Russ" Cc: Derek Atkins , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@MIT.EDU Subject: Re: [saag] RE: AES Counter Mode Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Feb 2002 10:00:42 -0500 Message-Id: <20020228150042.0BF417B4B@berkshire.research.att.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: In message <5.1.0.14.2.20020228085148.0302a628@exna07.securitydynamics.com>, "H ousley, Russ" writes: > >The tables associated with the precomputation attacks are extremely large >and unwieldy. I think it is more likely that the keys would be extracted >from an implementation. The assurance of implementations needs to improve >significantly before the effort associated with such a precomputation >attack would even be considered by an attacker. > Yes, extracting the keys from an implementation -- due to buggy software, a stolen laptop, a disgruntled employee, etc. -- is the biggest problem. But the issue that I believe Derek is talking about isn't precomputation, it's reuse of a counter. The Borisov/ Goldberg/ Wagner paper pointed out that many implementations start the variable portion of their counter at 0 each time they're power-cycled. This lets me attack the *upstream* traffic from, say, a laptop, and the upstream traffic is much more likely to have passwords. The attack isn't precomputation, it's XORing two ciphertext streams against each other, producing the XOR of two plaintext streams -- and that's generally easy to tease apart. Yes, it's good that the MAC address is part of the counter, since that does segregate different traffic sources. But unless another portion of the initial counter value is high-quality random, there's likely to be trouble, especially given how long keys last in an 802.11 environment. How should the initial counter be constructed? Per Appendix B of the NIST spec, we want one portion that is incremented for each message, and one portion that is incremented for each block in a message. We have 128 bits to play with. MAC addresses are going to 8 bytes, which eats up 64 bits. There's a push to increase packet sizes to 9K; at 16 bytes/block, we need 10 bits for blocks within a packet. That leaves 54 bits. If those 54 are chosen as a true-random number, the odds on a collision are 50% in 2^27 "sessions". That's acceptable. But we need to figure in the length of a session -- that is, how many packets are sent starting with some given value. I don't have the time now to work this exactly, but (assuming that I'm doing the math right, which is always a dicey question when it comes to me doing even slightly complex probability calculations) I think we're close to the edge. Let's assume, to be safe, that a "session" is 1,000,000 packets, which is ~2^20. (That may be too low -- my laptop has been up for a week, and it's received 1.6 million packets just on its wired interface in that time. VoIP and video will generate long packet streams.) If we want to avoid any overlap of the counter space -- and we do -- we have 2^34 possible disjoint spaces. By the birthday paradox, the probability of a match is about 50% with 2^17 sessions. (I'd *really* like it if someone checked my math here...) Would one laptop have 2^17 sessions of 2^20 packets each? Probably not -- at 20 reboots a day (which is a lot even for Windows), it would take about 18 years to reach that many. Access points send lots of packets, but they aren't power-cycled that often. But it's close enough to make me nervous; I've seen enough other parameters change by an order of magnitude or more in just a few years. (In 1994, I annoyed my wife by insisting that our new PC needed huge amounts of disk and RAM -- 500M and 32M.) What should be done? My preferred answer is to use CBC mode. IV collisions there leak information that two packets have a common prefix; it says nothing about the contents of the packet, and in IPv4 the first block of the IP header will generally differ because of the IP "id" field. (We won't get that advantage in IPv6, however, and some implementations of v4 use constant "id" fields most of the time.) But that's not a critical leakage, compared with counter mode where plaintext is leaked. But the *real* answer is to add key management, in which case none of the rest of this matters! --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From warlord@MIT.EDU Thu Feb 28 10:31:20 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA14566 for ; Thu, 28 Feb 2002 10:31:20 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA25299; Thu, 28 Feb 2002 10:31:13 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA28806; Thu, 28 Feb 2002 10:31:12 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA03499; Thu, 28 Feb 2002 10:31:11 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA05825; Thu, 28 Feb 2002 10:31:10 -0500 (EST) To: "Steven M. Bellovin" Cc: "Housley, Russ" , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@MIT.EDU From: Derek Atkins Subject: Re: [saag] RE: AES Counter Mode References: <20020228150042.0BF417B4B@berkshire.research.att.com> Date: 28 Feb 2002 10:31:10 -0500 In-Reply-To: <20020228150042.0BF417B4B@berkshire.research.att.com> Message-ID: Lines: 120 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Indeed, I was worried about IV-reuse, and the MAC is taking up 50% of your space, which mean you really only have 2^64 space to check (per device). Also, the A/P winds up getting/sending the most traffic in your wireless network. To add fuel to steve's fire, here are some numbers from my laptop: RX packets:2483405 errors:0 dropped:0 overruns:0 frame:0 TX packets:2573655 errors:0 dropped:0 overruns:0 carrier:0 10:21am up 15 days, 14:09, 6 users, load average: 0.52, 0.47, 0.50 Similarly, how often do you expect the WEP key to change? I would say "never", because it's all manual key management and nobody likes flag-days. I agree that I'd prefer a CBC mode with random explicit IV per packet, although then you need a decent RNG in your cards. I think the biggest potential flaw with 802.11 will be new-found XOR attacks. CBC will fix that completely. Honestly what I'd REALLY like to see is real key management, so you could have an individual encryption key for every user in the system. One approach is to perform an ephemeral DH per 'pair' of communicating devices. In infrastructure mode you would perform a key agreement when you attach to the network and use that for the length of your session. Before I left Telcordia I even came up with a protocol that would let you fit this into the existing 802.11 authentication scheme. Alas, this protocol was left in their hands. Steve, I happen to somewhat disagree that real key management would make the other issues disappear. It would mitigate them a bit, but not eliminate them. The XOR class of attacks would still exist, although it might be harder to pull them off. -derek "Steven M. Bellovin" writes: > In message <5.1.0.14.2.20020228085148.0302a628@exna07.securitydynamics.com>, "H > ousley, Russ" writes: > > > > >The tables associated with the precomputation attacks are extremely large > >and unwieldy. I think it is more likely that the keys would be extracted > >from an implementation. The assurance of implementations needs to improve > >significantly before the effort associated with such a precomputation > >attack would even be considered by an attacker. > > > > Yes, extracting the keys from an implementation -- due to buggy > software, a stolen laptop, a disgruntled employee, etc. -- is the > biggest problem. But the issue that I believe Derek is talking > about isn't precomputation, it's reuse of a counter. The Borisov/ > Goldberg/ Wagner paper pointed out that many implementations start > the variable portion of their counter at 0 each time they're > power-cycled. This lets me attack the *upstream* traffic from, > say, a laptop, and the upstream traffic is much more likely to have > passwords. The attack isn't precomputation, it's XORing two > ciphertext streams against each other, producing the XOR of two > plaintext streams -- and that's generally easy to tease apart. > > Yes, it's good that the MAC address is part of the counter, since > that does segregate different traffic sources. But unless another > portion of the initial counter value is high-quality random, there's > likely to be trouble, especially given how long keys last in an > 802.11 environment. > > How should the initial counter be constructed? Per Appendix B of > the NIST spec, we want one portion that is incremented for each > message, and one portion that is incremented for each block in a > message. We have 128 bits to play with. MAC addresses are going > to 8 bytes, which eats up 64 bits. There's a push to increase > packet sizes to 9K; at 16 bytes/block, we need 10 bits for blocks > within a packet. That leaves 54 bits. If those 54 are chosen as > a true-random number, the odds on a collision are 50% in 2^27 > "sessions". That's acceptable. But we need to figure in the length > of a session -- that is, how many packets are sent starting with > some given value. I don't have the time now to work this exactly, > but (assuming that I'm doing the math right, which is always a > dicey question when it comes to me doing even slightly complex > probability calculations) I think we're close to the edge. Let's > assume, to be safe, that a "session" is 1,000,000 packets, which > is ~2^20. (That may be too low -- my laptop has been up for a > week, and it's received 1.6 million packets just on its wired > interface in that time. VoIP and video will generate long packet > streams.) If we want to avoid any overlap of the counter space -- > and we do -- we have 2^34 possible disjoint spaces. By the birthday > paradox, the probability of a match is about 50% with 2^17 sessions. > (I'd *really* like it if someone checked my math here...) > > Would one laptop have 2^17 sessions of 2^20 packets each? Probably > not -- at 20 reboots a day (which is a lot even for Windows), it > would take about 18 years to reach that many. Access points send > lots of packets, but they aren't power-cycled that often. But it's > close enough to make me nervous; I've seen enough other parameters > change by an order of magnitude or more in just a few years. (In > 1994, I annoyed my wife by insisting that our new PC needed huge > amounts of disk and RAM -- 500M and 32M.) > > What should be done? My preferred answer is to use CBC mode. IV > collisions there leak information that two packets have a common > prefix; it says nothing about the contents of the packet, and in > IPv4 the first block of the IP header will generally differ because > of the IP "id" field. (We won't get that advantage in IPv6, however, > and some implementations of v4 use constant "id" fields most of > the time.) But that's not a critical leakage, compared with counter > mode where plaintext is leaked. > > But the *real* answer is to add key management, in which case none of > the rest of this matters! > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From mcgrew@cisco.com Thu Feb 28 10:36:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA14689 for ; Thu, 28 Feb 2002 10:36:18 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA27122 for ; Thu, 28 Feb 2002 10:36:17 -0500 (EST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1SFYih10884; Thu, 28 Feb 2002 07:36:08 -0800 (PST) Received: from MCGREWW2K ([10.34.251.98]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAX72448; Thu, 28 Feb 2002 07:30:19 -0800 (PST) From: "David A. Mcgrew" To: "Steven M. Bellovin" , "Housley, Russ" Cc: "Derek Atkins" , "Walker, Jesse" , "Vincenzo Liguori" , Subject: RE: [saag] RE: AES Counter Mode Date: Thu, 28 Feb 2002 07:32:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020228150042.0BF417B4B@berkshire.research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steve, > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Thursday, February 28, 2002 7:01 AM > To: Housley, Russ > Cc: Derek Atkins; David A. Mcgrew; Walker, Jesse; Vincenzo Liguori; > saag@MIT.EDU > Subject: Re: [saag] RE: AES Counter Mode > > > In message > <5.1.0.14.2.20020228085148.0302a628@exna07.securitydynamics.com>, "H > ousley, Russ" writes: > > > > >The tables associated with the precomputation attacks are > extremely large > >and unwieldy. I think it is more likely that the keys would be extracted > >from an implementation. The assurance of implementations needs > to improve > >significantly before the effort associated with such a precomputation > >attack would even be considered by an attacker. > > > > Yes, extracting the keys from an implementation -- due to buggy > software, a stolen laptop, a disgruntled employee, etc. -- is the > biggest problem. But the issue that I believe Derek is talking > about isn't precomputation, it's reuse of a counter. The Borisov/ > Goldberg/ Wagner paper pointed out that many implementations start > the variable portion of their counter at 0 each time they're > power-cycled. This lets me attack the *upstream* traffic from, > say, a laptop, and the upstream traffic is much more likely to have > passwords. The attack isn't precomputation, it's XORing two > ciphertext streams against each other, producing the XOR of two > plaintext streams -- and that's generally easy to tease apart. > > Yes, it's good that the MAC address is part of the counter, since > that does segregate different traffic sources. But unless another > portion of the initial counter value is high-quality random, there's > likely to be trouble, especially given how long keys last in an > 802.11 environment. > > How should the initial counter be constructed? this is the $64k question. As you mention, the counter needs to contain some certain number of unpredictable bits. But this unpredictability need not be restricted to a particular field. The counter can be constructed by adding (or exoring) a value constructed using some particular formatting with a salt value (this is what draft-mcgrew-saag-icm-00.txt does, and what the early 802.11 proposal that I saw did as well). So the need for counter unpredictability can be met without restricting the amount of data protected. Of course, with AES CTR mode no more than 2^64 blocks can be protected with any fixed key, but this limitation is unavoidable with any cipher mode. David > Per Appendix B of > the NIST spec, we want one portion that is incremented for each > message, and one portion that is incremented for each block in a > message. We have 128 bits to play with. MAC addresses are going > to 8 bytes, which eats up 64 bits. There's a push to increase > packet sizes to 9K; at 16 bytes/block, we need 10 bits for blocks > within a packet. That leaves 54 bits. If those 54 are chosen as > a true-random number, the odds on a collision are 50% in 2^27 > "sessions". That's acceptable. But we need to figure in the length > of a session -- that is, how many packets are sent starting with > some given value. I don't have the time now to work this exactly, > but (assuming that I'm doing the math right, which is always a > dicey question when it comes to me doing even slightly complex > probability calculations) I think we're close to the edge. Let's > assume, to be safe, that a "session" is 1,000,000 packets, which > is ~2^20. (That may be too low -- my laptop has been up for a > week, and it's received 1.6 million packets just on its wired > interface in that time. VoIP and video will generate long packet > streams.) If we want to avoid any overlap of the counter space -- > and we do -- we have 2^34 possible disjoint spaces. By the birthday > paradox, the probability of a match is about 50% with 2^17 sessions. > (I'd *really* like it if someone checked my math here...) > > Would one laptop have 2^17 sessions of 2^20 packets each? Probably > not -- at 20 reboots a day (which is a lot even for Windows), it > would take about 18 years to reach that many. Access points send > lots of packets, but they aren't power-cycled that often. But it's > close enough to make me nervous; I've seen enough other parameters > change by an order of magnitude or more in just a few years. (In > 1994, I annoyed my wife by insisting that our new PC needed huge > amounts of disk and RAM -- 500M and 32M.) > > What should be done? My preferred answer is to use CBC mode. IV > collisions there leak information that two packets have a common > prefix; it says nothing about the contents of the packet, and in > IPv4 the first block of the IP header will generally differ because > of the IP "id" field. (We won't get that advantage in IPv6, however, > and some implementations of v4 use constant "id" fields most of > the time.) But that's not a critical leakage, compared with counter > mode where plaintext is leaked. > > But the *real* answer is to add key management, in which case none of > the rest of this matters! > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com From kent@bbn.com Thu Feb 28 10:51:14 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA14937 for ; Thu, 28 Feb 2002 10:51:14 -0500 (EST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA21093 for ; Thu, 28 Feb 2002 10:51:14 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA14352; Thu, 28 Feb 2002 10:49:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <20020228150042.0BF417B4B@berkshire.research.att.com> References: <20020228150042.0BF417B4B@berkshire.research.att.com> Date: Thu, 28 Feb 2002 10:43:40 -0500 To: "Steven M. Bellovin" From: Stephen Kent Subject: Re: [saag] RE: AES Counter Mode Cc: "Housley, Russ" , Derek Atkins , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 10:00 AM -0500 2/28/02, Steven M. Bellovin wrote: >In message ><5.1.0.14.2.20020228085148.0302a628@exna07.securitydynamics.com>, "H >ousley, Russ" writes: > >> >>The tables associated with the precomputation attacks are extremely large >>and unwieldy. I think it is more likely that the keys would be extracted >>from an implementation. The assurance of implementations needs to improve >>significantly before the effort associated with such a precomputation >>attack would even be considered by an attacker. >> > >Yes, extracting the keys from an implementation -- due to buggy >software, a stolen laptop, a disgruntled employee, etc. -- is the >biggest problem. But the issue that I believe Derek is talking >about isn't precomputation, it's reuse of a counter. The Borisov/ >Goldberg/ Wagner paper pointed out that many implementations start >the variable portion of their counter at 0 each time they're >power-cycled. This lets me attack the *upstream* traffic from, >say, a laptop, and the upstream traffic is much more likely to have >passwords. The attack isn't precomputation, it's XORing two >ciphertext streams against each other, producing the XOR of two >plaintext streams -- and that's generally easy to tease apart. > >Yes, it's good that the MAC address is part of the counter, since >that does segregate different traffic sources. But unless another >portion of the initial counter value is high-quality random, there's >likely to be trouble, especially given how long keys last in an >802.11 environment. > >How should the initial counter be constructed? Per Appendix B of >the NIST spec, we want one portion that is incremented for each >message, and one portion that is incremented for each block in a >message. We have 128 bits to play with. MAC addresses are going >to 8 bytes, which eats up 64 bits. There's a push to increase >packet sizes to 9K; at 16 bytes/block, we need 10 bits for blocks >within a packet. That leaves 54 bits. If those 54 are chosen as >a true-random number, the odds on a collision are 50% in 2^27 >"sessions". That's acceptable. But we need to figure in the length >of a session -- that is, how many packets are sent starting with >some given value. I don't have the time now to work this exactly, >but (assuming that I'm doing the math right, which is always a >dicey question when it comes to me doing even slightly complex >probability calculations) I think we're close to the edge. Let's >assume, to be safe, that a "session" is 1,000,000 packets, which >is ~2^20. (That may be too low -- my laptop has been up for a >week, and it's received 1.6 million packets just on its wired >interface in that time. VoIP and video will generate long packet >streams.) If we want to avoid any overlap of the counter space -- >and we do -- we have 2^34 possible disjoint spaces. By the birthday >paradox, the probability of a match is about 50% with 2^17 sessions. >(I'd *really* like it if someone checked my math here...) > >Would one laptop have 2^17 sessions of 2^20 packets each? Probably >not -- at 20 reboots a day (which is a lot even for Windows), it >would take about 18 years to reach that many. Access points send >lots of packets, but they aren't power-cycled that often. But it's >close enough to make me nervous; I've seen enough other parameters >change by an order of magnitude or more in just a few years. (In >1994, I annoyed my wife by insisting that our new PC needed huge >amounts of disk and RAM -- 500M and 32M.) > >What should be done? My preferred answer is to use CBC mode. IV >collisions there leak information that two packets have a common >prefix; it says nothing about the contents of the packet, and in >IPv4 the first block of the IP header will generally differ because >of the IP "id" field. (We won't get that advantage in IPv6, however, >and some implementations of v4 use constant "id" fields most of >the time.) But that's not a critical leakage, compared with counter >mode where plaintext is leaked. > >But the *real* answer is to add key management, in which case none of >the rest of this matters! > I concur with Steve's suggestion, i.e., in the IPsec context I would like to see an IV used with each packet in a CTR mode. Such use also has a benefit for implementations in which multiple crypto chips are used to serve a set of subscribers, e.g., POP vs. CPE deployment. The benefit is that it usually is not feasible to synch per-packet counters among the chips, and if the counter value is maintained outside the chips, then the boundary for security evaluation re this basic crypto function is greatly expanded. One can generate IVs on a per chip basis and avoid expanding the evaluation boundary. Steve From HUITEMA@windows.microsoft.com Thu Feb 28 11:03:59 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA15171 for ; Thu, 28 Feb 2002 11:03:58 -0500 (EST) Received: from mail6.microsoft.com (mailc.microsoft.com [131.107.3.126]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA26388 for ; Thu, 28 Feb 2002 11:03:58 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Feb 2002 08:03:04 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Feb 2002 08:03:03 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 08:03:03 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 08:03:03 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 28 Feb 2002 08:01:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Do we need some randomness in the IPv6 header? (was RE: [saag] RE: AES Counter Mode) Date: Thu, 28 Feb 2002 08:01:09 -0800 Message-ID: Thread-Topic: Do we need some randomness in the IPv6 header? (was RE: [saag] RE: AES Counter Mode) thread-index: AcHAbEF8C9UIqIzvQ6+VzgeDAztxlQABI0cw From: "Christian Huitema" To: "Steven M. Bellovin" Cc: X-OriginalArrivalTime: 28 Feb 2002 16:01:09.0919 (UTC) FILETIME=[234D4AF0:01C1C071] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id LAA15171 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > What should be done? My preferred answer is to use CBC mode. IV > collisions there leak information that two packets have a common > prefix; it says nothing about the contents of the packet, and in > IPv4 the first block of the IP header will generally differ because > of the IP "id" field. (We won't get that advantage in IPv6, however, > and some implementations of v4 use constant "id" fields most of > the time.) But that's not a critical leakage, compared with counter > mode where plaintext is leaked. Steve, Should I follow your reasoning and modify our IPv6 implementation to force some randomness in the IPv6 header? It is not impossible, since the first 32 bits of the header includes a 20 bit flow-id whose purpose is currently ill defined. We could easily place a random number there. Would that be more valuable than other uses we currently plan, such as indicating QoS profiles for diffserv, or indicating unique flow identifiers for intserv? -- Christian Huitema From rhousley@rsasecurity.com Thu Feb 28 12:12:23 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA16134 for ; Thu, 28 Feb 2002 12:12:23 -0500 (EST) Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id MAA28289 for ; Thu, 28 Feb 2002 12:12:23 -0500 (EST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for FORT-POINT-STATION.MIT.EDU [18.7.7.76]) with SMTP; 28 Feb 2002 17:12:04 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA28947; Thu, 28 Feb 2002 12:12:11 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1SHCLs25375; Thu, 28 Feb 2002 12:12:21 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 12:10:11 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.106]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NQ9X; Thu, 28 Feb 2002 12:10:00 -0500 From: "Housley, Russ" To: "Steven M. Bellovin" Cc: Derek Atkins , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@MIT.EDU Message-Id: <5.1.0.14.2.20020228111158.030dbbe0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 12:12:06 -0500 Subject: Re: [saag] RE: AES Counter Mode In-Reply-To: <20020228150042.0BF417B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steve: > >The tables associated with the precomputation attacks are extremely large > >and unwieldy. I think it is more likely that the keys would be extracted > >from an implementation. The assurance of implementations needs to improve > >significantly before the effort associated with such a precomputation > >attack would even be considered by an attacker. > >Yes, extracting the keys from an implementation -- due to buggy >software, a stolen laptop, a disgruntled employee, etc. -- is the >biggest problem. But the issue that I believe Derek is talking >about isn't precomputation, it's reuse of a counter. The Borisov/ >Goldberg/ Wagner paper pointed out that many implementations start >the variable portion of their counter at 0 each time they're >power-cycled. This lets me attack the *upstream* traffic from, >say, a laptop, and the upstream traffic is much more likely to have >passwords. The attack isn't precomputation, it's XORing two >ciphertext streams against each other, producing the XOR of two >plaintext streams -- and that's generally easy to tease apart. As part of the IEEE 802.11 proposal, as in David McGrew's Internet-Drafts, the counter block include two values. The first is a packet counter. This value must be transmitted for synchronization of the encryptor and the decryptor. I think of this as an IV. The second is a block counter within the packet. This value does not need to be transmitted. It is starts from zero for each packet. If two different packets use the same IV, then there is a concern. In the IEEE 802.11 proposal, we ensure that this does not happen two ways. First, a new key must be established when the station associates with the access point. This prevents the reuse of the same key stream due to a reboot. Second, a new key must be established when the IV space on the previous key is exhausted. This prevents reuse of the same key stream by having the IV wrap around. >Yes, it's good that the MAC address is part of the counter, since >that does segregate different traffic sources. But unless another >portion of the initial counter value is high-quality random, there's >likely to be trouble, especially given how long keys last in an >802.11 environment. Part of the fix to WEP is a rekey protocol. Any long-lived key will be a key-encryption key, not a packet-encryption key. >How should the initial counter be constructed? Per Appendix B of >the NIST spec, we want one portion that is incremented for each >message, and one portion that is incremented for each block in a >message. We have 128 bits to play with. MAC addresses are going >to 8 bytes, which eats up 64 bits. There's a push to increase >packet sizes to 9K; at 16 bytes/block, we need 10 bits for blocks >within a packet. That leaves 54 bits. If those 54 are chosen as >a true-random number, the odds on a collision are 50% in 2^27 >"sessions". That's acceptable. But we need to figure in the length >of a session -- that is, how many packets are sent starting with >some given value. I don't have the time now to work this exactly, >but (assuming that I'm doing the math right, which is always a >dicey question when it comes to me doing even slightly complex >probability calculations) I think we're close to the edge. Let's >assume, to be safe, that a "session" is 1,000,000 packets, which >is ~2^20. (That may be too low -- my laptop has been up for a >week, and it's received 1.6 million packets just on its wired >interface in that time. VoIP and video will generate long packet >streams.) If we want to avoid any overlap of the counter space -- >and we do -- we have 2^34 possible disjoint spaces. By the birthday >paradox, the probability of a match is about 50% with 2^17 sessions. >(I'd *really* like it if someone checked my math here...) In 802.11, MAC addresses are 48 bits. So, the counter block includes: 1 octet for the flag, we need this in order to provide confidentiality and integrity with a single AES key (wait for the paper); 6 octets for the MAC address; 4 octets for the IV (the per packet counter); 4 octets for the cipher block counter; and 1 octet left over (a constant). Again, when the IV space is exhausted, one must rekey. With this counter block structure, each station can transmit 2^32 packets under one key. Usually, there will only be two stations that have any key (another change over the current WEP), but we need to accommodate encryption of broadcast and multicast too. The use of 4 octets for the cipher block counter imposes a maximum packet size of 16* 2^32 octets. I do not think that any IPsec or Wireless LAN packet will exceed 68,719,476,736 octets. Obviously, if we needed space for something else, we could reduce this value. However, there are performance advantages on many platforms for using a 32-bit value here. >Would one laptop have 2^17 sessions of 2^20 packets each? Probably >not -- at 20 reboots a day (which is a lot even for Windows), it >would take about 18 years to reach that many. Access points send >lots of packets, but they aren't power-cycled that often. But it's >close enough to make me nervous; I've seen enough other parameters >change by an order of magnitude or more in just a few years. (In >1994, I annoyed my wife by insisting that our new PC needed huge >amounts of disk and RAM -- 500M and 32M.) > >What should be done? My preferred answer is to use CBC mode. IV >collisions there leak information that two packets have a common >prefix; it says nothing about the contents of the packet, and in >IPv4 the first block of the IP header will generally differ because >of the IP "id" field. (We won't get that advantage in IPv6, however, >and some implementations of v4 use constant "id" fields most of >the time.) But that's not a critical leakage, compared with counter >mode where plaintext is leaked. With DHCP and NAT, I am not sure that the IPsec environment has an equivalent to the MAC address. I understand the reasons that you like CBC mode. I like to too. The only real drawback to CBC is the requirement to pad the final block. The Wireless community does not like to transmit any extra bits. >But the *real* answer is to add key management, in which case none of >the rest of this matters! I agree. As should be clear by now, this is being done. Russ From rhousley@rsasecurity.com Thu Feb 28 12:24:39 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA16326 for ; Thu, 28 Feb 2002 12:24:38 -0500 (EST) Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id MAA03384 for ; Thu, 28 Feb 2002 12:24:38 -0500 (EST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for FORT-POINT-STATION.MIT.EDU [18.7.7.76]) with SMTP; 28 Feb 2002 17:24:20 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA29744; Thu, 28 Feb 2002 12:24:27 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1SHOae26249; Thu, 28 Feb 2002 12:24:37 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 12:22:27 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.106]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NR19; Thu, 28 Feb 2002 12:22:24 -0500 From: "Housley, Russ" To: Derek Atkins Cc: "Steven M. Bellovin" , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@MIT.EDU Message-Id: <5.1.0.14.2.20020228121319.030d3c50@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 12:20:06 -0500 Subject: Re: [saag] RE: AES Counter Mode In-Reply-To: References: <20020228150042.0BF417B4B@berkshire.research.att.com> <20020228150042.0BF417B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Derek: >Indeed, I was worried about IV-reuse, and the MAC is taking up 50% of >your space, which mean you really only have 2^64 space to check (per >device). Also, the A/P winds up getting/sending the most traffic in >your wireless network. Sorry. I think this miscommunication has been resolved. >To add fuel to steve's fire, here are some numbers from my laptop: > > RX packets:2483405 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2573655 errors:0 dropped:0 overruns:0 carrier:0 > 10:21am up 15 days, 14:09, 6 users, load average: 0.52, 0.47, 0.50 > >Similarly, how often do you expect the WEP key to change? I would >say "never", because it's all manual key management and nobody likes >flag-days. As should be clear from my reply to Steve's message, I expect the packet-encryption key to change frequently. Any long-term key will be a key-encryption key. >I agree that I'd prefer a CBC mode with random explicit IV per packet, >although then you need a decent RNG in your cards. I think the >biggest potential flaw with 802.11 will be new-found XOR attacks. CBC >will fix that completely. One concern is that some of the low-power devices do not have a good entropy source. >Honestly what I'd REALLY like to see is real key management, so you >could have an individual encryption key for every user in the system. >One approach is to perform an ephemeral DH per 'pair' of communicating >devices. In infrastructure mode you would perform a key agreement >when you attach to the network and use that for the length of your >session. Before I left Telcordia I even came up with a protocol that >would let you fit this into the existing 802.11 authentication scheme. >Alas, this protocol was left in their hands. Again, it should be clear by now that this is the direction that IEEE 802.11 TGi is taking. Russ From warlord@MIT.EDU Thu Feb 28 12:37:19 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA16530 for ; Thu, 28 Feb 2002 12:37:19 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA08225; Thu, 28 Feb 2002 12:37:01 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17526; Thu, 28 Feb 2002 12:37:01 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id MAA12203; Thu, 28 Feb 2002 12:36:59 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA06079; Thu, 28 Feb 2002 12:36:58 -0500 (EST) To: "Housley, Russ" Cc: "Steven M. Bellovin" , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@MIT.EDU From: Derek Atkins Subject: Re: [saag] RE: AES Counter Mode References: <20020228150042.0BF417B4B@berkshire.research.att.com> <20020228150042.0BF417B4B@berkshire.research.att.com> <5.1.0.14.2.20020228121319.030d3c50@exna07.securitydynamics.com> Date: 28 Feb 2002 12:36:57 -0500 In-Reply-To: <5.1.0.14.2.20020228121319.030d3c50@exna07.securitydynamics.com> Message-ID: Lines: 70 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Russ, Yea, it appears there has been some cross-communication. I'm glad to hear that 802.11 is taking the route of an ephemeral packet-encryption-key. That is definitely the right way to go. I would also be 'nice' if there were alternate algorithms for how to generate/use/present the key-encryption-key. For example, it would be nice if you could use Kerberos or some other infrastructure for end-point identificiation, authentication, or authorization. I would be interested in seeing the proposed key-agreement protocol, especially given your statement that some low-power devices may not have decent sources of entropy.... -derek "Housley, Russ" writes: > Derek: > > >Indeed, I was worried about IV-reuse, and the MAC is taking up 50% of > >your space, which mean you really only have 2^64 space to check (per > >device). Also, the A/P winds up getting/sending the most traffic in > >your wireless network. > > Sorry. I think this miscommunication has been resolved. > > >To add fuel to steve's fire, here are some numbers from my laptop: > > > > RX packets:2483405 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:2573655 errors:0 dropped:0 overruns:0 carrier:0 > > 10:21am up 15 days, 14:09, 6 users, load average: 0.52, 0.47, 0.50 > > > >Similarly, how often do you expect the WEP key to change? I would > >say "never", because it's all manual key management and nobody likes > >flag-days. > > As should be clear from my reply to Steve's message, I expect the > packet-encryption key to change frequently. Any long-term key will be > a key-encryption key. > > >I agree that I'd prefer a CBC mode with random explicit IV per packet, > >although then you need a decent RNG in your cards. I think the > >biggest potential flaw with 802.11 will be new-found XOR attacks. CBC > >will fix that completely. > > One concern is that some of the low-power devices do not have a good > entropy source. > > >Honestly what I'd REALLY like to see is real key management, so you > >could have an individual encryption key for every user in the system. > >One approach is to perform an ephemeral DH per 'pair' of communicating > >devices. In infrastructure mode you would perform a key agreement > >when you attach to the network and use that for the length of your > >session. Before I left Telcordia I even came up with a protocol that > >would let you fit this into the existing 802.11 authentication scheme. > >Alas, this protocol was left in their hands. > > Again, it should be clear by now that this is the direction that IEEE > 802.11 TGi is taking. > > Russ -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From kalpana_mahanta@hotmail.com Thu Feb 28 12:58:01 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA16803 for ; Thu, 28 Feb 2002 12:58:01 -0500 (EST) Received: from hotmail.com (law2-f107.hotmail.com [216.32.181.107]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25031 for ; Thu, 28 Feb 2002 12:58:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Feb 2002 09:58:00 -0800 Received: from 63.78.179.5 by lw2fd.hotmail.msn.com with HTTP; Thu, 28 Feb 2002 17:58:00 GMT X-Originating-IP: [63.78.179.5] From: "Kalpana Mahanta" To: saag@mit.edu Date: Thu, 28 Feb 2002 11:58:00 -0600 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 28 Feb 2002 17:58:00.0335 (UTC) FILETIME=[75D5E1F0:01C1C081] Subject: [saag] Please remove my email add from your mailing list!!!!!!!!!! Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive:

I keep recieving emails which I do not have time to read..so please do me a favor...remove my name from your list.

Thanks.


Send and receive Hotmail on your mobile device: Click Here
From mandeep.toor@cudirect.com Thu Feb 28 13:20:45 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA17145 for ; Thu, 28 Feb 2002 13:20:45 -0500 (EST) Received: from relay.cudirect.com ([65.200.30.14]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id NAA04147 for ; Thu, 28 Feb 2002 13:20:44 -0500 (EST) Received: by cudlmsx.cudirect.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 10:20:46 -0800 Message-ID: <4D8596A3504AD511888200B0D0DE7FE211CF1E@cudlmsx.cudirect.com> From: Mandeep Toor To: "'saag@mit.edu'" Date: Thu, 28 Feb 2002 10:20:46 -0800 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C084.A3E192D0" Subject: [saag] unsubscribe Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C084.A3E192D0 Content-Type: text/plain Please remove me from your list. Mandeep Toor ------_=_NextPart_001_01C1C084.A3E192D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Please remove me from your = list.

 

Mandeep Toor 

 

------_=_NextPart_001_01C1C084.A3E192D0-- From rhousley@rsasecurity.com Thu Feb 28 13:24:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA17202 for ; Thu, 28 Feb 2002 13:24:27 -0500 (EST) Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id NAA27812 for ; Thu, 28 Feb 2002 13:24:27 -0500 (EST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for FORT-POINT-STATION.MIT.EDU [18.7.7.76]) with SMTP; 28 Feb 2002 18:24:08 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA03157; Thu, 28 Feb 2002 13:24:16 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1SIOOq29969; Thu, 28 Feb 2002 13:24:24 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 13:22:14 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.30]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5NSAS; Thu, 28 Feb 2002 13:22:02 -0500 From: "Housley, Russ" To: Derek Atkins Cc: "Steven M. Bellovin" , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@MIT.EDU Message-Id: <5.1.0.14.2.20020228131933.02fe68a0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 13:21:45 -0500 Subject: Re: [saag] RE: AES Counter Mode In-Reply-To: References: <5.1.0.14.2.20020228121319.030d3c50@exna07.securitydynamics.com> <20020228150042.0BF417B4B@berkshire.research.att.com> <20020228150042.0BF417B4B@berkshire.research.att.com> <5.1.0.14.2.20020228121319.030d3c50@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Derek: Feel free to participate. The current approach will use EAP to establish a master key. EAP is flexible enough to accommodate a wide range of solutions. I hope that it is not too much flexibility to permit widespread interoperation. Russ At 12:36 PM 2/28/2002 -0500, Derek Atkins wrote: >Russ, > >Yea, it appears there has been some cross-communication. >I'm glad to hear that 802.11 is taking the route of an >ephemeral packet-encryption-key. That is definitely >the right way to go. > >I would also be 'nice' if there were alternate algorithms >for how to generate/use/present the key-encryption-key. >For example, it would be nice if you could use Kerberos >or some other infrastructure for end-point identificiation, >authentication, or authorization. > >I would be interested in seeing the proposed key-agreement >protocol, especially given your statement that some low-power >devices may not have decent sources of entropy.... > >-derek > >"Housley, Russ" writes: > > > Derek: > > > > >Indeed, I was worried about IV-reuse, and the MAC is taking up 50% of > > >your space, which mean you really only have 2^64 space to check (per > > >device). Also, the A/P winds up getting/sending the most traffic in > > >your wireless network. > > > > Sorry. I think this miscommunication has been resolved. > > > > >To add fuel to steve's fire, here are some numbers from my laptop: > > > > > > RX packets:2483405 errors:0 dropped:0 overruns:0 frame:0 > > > TX packets:2573655 errors:0 dropped:0 overruns:0 carrier:0 > > > 10:21am up 15 days, 14:09, 6 users, load average: 0.52, 0.47, 0.50 > > > > > >Similarly, how often do you expect the WEP key to change? I would > > >say "never", because it's all manual key management and nobody likes > > >flag-days. > > > > As should be clear from my reply to Steve's message, I expect the > > packet-encryption key to change frequently. Any long-term key will be > > a key-encryption key. > > > > >I agree that I'd prefer a CBC mode with random explicit IV per packet, > > >although then you need a decent RNG in your cards. I think the > > >biggest potential flaw with 802.11 will be new-found XOR attacks. CBC > > >will fix that completely. > > > > One concern is that some of the low-power devices do not have a good > > entropy source. > > > > >Honestly what I'd REALLY like to see is real key management, so you > > >could have an individual encryption key for every user in the system. > > >One approach is to perform an ephemeral DH per 'pair' of communicating > > >devices. In infrastructure mode you would perform a key agreement > > >when you attach to the network and use that for the length of your > > >session. Before I left Telcordia I even came up with a protocol that > > >would let you fit this into the existing 802.11 authentication scheme. > > >Alas, this protocol was left in their hands. > > > > Again, it should be clear by now that this is the direction that IEEE > > 802.11 TGi is taking. > > > > Russ > >-- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From kent@bbn.com Thu Feb 28 13:31:07 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA17322 for ; Thu, 28 Feb 2002 13:31:07 -0500 (EST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA09136 for ; Thu, 28 Feb 2002 13:31:07 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA11192; Thu, 28 Feb 2002 13:29:26 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5.1.0.14.2.20020228111158.030dbbe0@exna07.securitydynamics.com> References: <5.1.0.14.2.20020228111158.030dbbe0@exna07.securitydynamics.com> Date: Thu, 28 Feb 2002 13:23:05 -0500 To: "Housley, Russ" From: Stephen Kent Subject: Re: [saag] RE: AES Counter Mode Cc: "Steven M. Bellovin" , Derek Atkins , "David A. Mcgrew" , "Walker, Jesse" , Vincenzo Liguori , saag@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 12:12 PM -0500 2/28/02, Housley, Russ wrote: >Steve: > >> >The tables associated with the precomputation attacks are extremely large >>>and unwieldy. I think it is more likely that the keys would be extracted >>>from an implementation. The assurance of implementations needs to improve >>>significantly before the effort associated with such a precomputation >>>attack would even be considered by an attacker. >> >>Yes, extracting the keys from an implementation -- due to buggy >>software, a stolen laptop, a disgruntled employee, etc. -- is the >>biggest problem. But the issue that I believe Derek is talking >>about isn't precomputation, it's reuse of a counter. The Borisov/ >>Goldberg/ Wagner paper pointed out that many implementations start >>the variable portion of their counter at 0 each time they're >>power-cycled. This lets me attack the *upstream* traffic from, >>say, a laptop, and the upstream traffic is much more likely to have >>passwords. The attack isn't precomputation, it's XORing two >>ciphertext streams against each other, producing the XOR of two >>plaintext streams -- and that's generally easy to tease apart. > >As part of the IEEE 802.11 proposal, as in David McGrew's >Internet-Drafts, the counter block include two values. The first is >a packet counter. This value must be transmitted for >synchronization of the encryptor and the decryptor. I think of this >as an IV. The second is a block counter within the packet. This >value does not need to be transmitted. It is starts from zero for >each packet. > I am very comfortable with that approach to splitting the input to counter mode; it's the same notion I have adopted in the last 6 months, as an evolution from a more complicated approach to using an IV that I briefed to the IPsec WG last summer. As you note, the critical requirement is to not duplicate the IV. The remaining challenge may be how to convince an evaluator (FIPS 140-x) that one can get reasonable assurance that the IV generators on multiple chips will yield distinct values (probabilistically?) so as to meet this requirement in implementations that choose to make use of multiple chips to serve the same SA. Steve From wayne.boaz@opbu.xerox.com Thu Feb 28 14:44:03 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA18332 for ; Thu, 28 Feb 2002 14:44:02 -0500 (EST) Received: from fw2.opbu.xerox.com (fw2.opbu.xerox.com [192.65.17.17]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA10482 for ; Thu, 28 Feb 2002 14:43:58 -0500 (EST) Received: from fw2.opbu.xerox.com (root@localhost) by fw2.opbu.xerox.com with ESMTP id g1SJjp321728 for ; Thu, 28 Feb 2002 11:45:51 -0800 (PST) Received: from mailhub.opbu.xerox.com (mailhub.opbu.xerox.com [13.62.6.81]) by fw2.opbu.xerox.com with ESMTP id g1SJjfA21664 for ; Thu, 28 Feb 2002 11:45:41 -0800 (PST) Received: from usawvas42 (UsaWvAS42.opbu.xerox.com [13.62.3.38]) by mailhub.opbu.xerox.com (8.9.3+Sun/8.9.3) with SMTP id LAA02767 for ; Thu, 28 Feb 2002 11:43:47 -0800 (PST) Received: FROM filtronix.opbu.xerox.com BY usawvas42 ; Thu Feb 28 11:43:46 2002 -0800 Received: from usawvbh01.opbu.xerox.com (UsaWvBH01.opbu.xerox.com [13.62.3.133]) by filtronix.opbu.xerox.com (8.10.2+Sun/8.10.2) with ESMTP id g1SJhiF06710; Thu, 28 Feb 2002 11:43:44 -0800 (PST) Received: by UsaWvBH01.opbu.xerox.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 11:43:45 -0800 Message-ID: <0BF8F21AC2C0D411B29300508B556399025D3098@UsaWvMS05.opbu.xerox.com> From: "Boaz, Wayne" To: "'Mandeep Toor'" , "'kalpana_mahanta@hotmail.com'" Cc: saag@mit.edu Subject: RE: [saag] unsubscribe Date: Thu, 28 Feb 2002 11:43:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C090.399BF3F0" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C090.399BF3F0 Content-Type: text/plain Unsubscribe here: http://jis.mit.edu/mailman/listinfo/saag at the bottom of the page. Wayne -----Original Message----- From: Mandeep Toor [mailto:mandeep.toor@cudirect.com] Sent: Thursday, February 28, 2002 10:21 AM To: 'saag@mit.edu' Subject: [saag] unsubscribe Importance: High Please remove me from your list. Mandeep Toor ------_=_NextPart_001_01C1C090.399BF3F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Unsubscribe here:
http://jis.mit.edu/mai= lman/listinfo/saag
at the=20 bottom of the page.
 
Wayne
 
-----Original Message-----
From: Mandeep Toor=20 [mailto:mandeep.toor@cudirect.com]
Sent: Thursday, February = 28, 2002=20 10:21 AM
To: 'saag@mit.edu'
Subject: [saag]=20 unsubscribe
Importance: High

Please remove = me from your=20 list.

 

Mandeep=20 Toor 

 

------_=_NextPart_001_01C1C090.399BF3F0-- From smb@research.att.com Thu Feb 28 15:03:14 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA18686 for ; Thu, 28 Feb 2002 15:03:14 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12313 for ; Thu, 28 Feb 2002 14:58:49 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id AD2AD1E0B1; Thu, 28 Feb 2002 14:58:43 -0500 (EST) Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA18947; Thu, 28 Feb 2002 14:54:50 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 8E3F27B4B; Thu, 28 Feb 2002 14:58:38 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Christian Huitema" Cc: saag@MIT.EDU Subject: Re: Do we need some randomness in the IPv6 header? (was RE: [saag] RE: AES Counter Mode) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Feb 2002 14:58:38 -0500 Message-Id: <20020228195838.8E3F27B4B@berkshire.research.att.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: In message , "Christian Huitema" writes: >> What should be done? My preferred answer is to use CBC mode. IV >> collisions there leak information that two packets have a common >> prefix; it says nothing about the contents of the packet, and in >> IPv4 the first block of the IP header will generally differ because >> of the IP "id" field. (We won't get that advantage in IPv6, however, >> and some implementations of v4 use constant "id" fields most of >> the time.) But that's not a critical leakage, compared with counter >> mode where plaintext is leaked. > >Steve, > >Should I follow your reasoning and modify our IPv6 implementation to >force some randomness in the IPv6 header? It is not impossible, since >the first 32 bits of the header includes a 20 bit flow-id whose purpose >is currently ill defined. We could easily place a random number there. >Would that be more valuable than other uses we currently plan, such as >indicating QoS profiles for diffserv, or indicating unique flow >identifiers for intserv? > No, there's no need to change anything in v6. The IV is supposed to handle that; I'm only talking about situations where there's an IV collision. That shouldn't happen anyway, and if it does you should fix that problem, but the consequences aren't serious enough to worry about in most environments. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From mcgrew@cisco.com Thu Feb 28 15:42:36 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA19178 for ; Thu, 28 Feb 2002 15:42:36 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA06861 for ; Thu, 28 Feb 2002 15:42:35 -0500 (EST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1SKgZt01052; Thu, 28 Feb 2002 12:42:35 -0800 (PST) Received: from MCGREWW2K ([10.34.251.98]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAX80003; Thu, 28 Feb 2002 12:38:10 -0800 (PST) From: "David A. Mcgrew" To: "Derek Atkins" Cc: "Housley, Russ" , "Walker, Jesse" , "Vincenzo Liguori" , Subject: RE: [saag] RE: AES Counter Mode Date: Thu, 28 Feb 2002 12:40:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Derek, > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Thursday, February 28, 2002 7:31 AM > To: Steven M. Bellovin > Cc: Housley, Russ; David A. Mcgrew; Walker, Jesse; Vincenzo Liguori; > saag@MIT.EDU > Subject: Re: [saag] RE: AES Counter Mode > > > Indeed, I was worried about IV-reuse, and the MAC is taking up 50% of > your space, which mean you really only have 2^64 space to check (per > device). Also, the A/P winds up getting/sending the most traffic in > your wireless network. > > To add fuel to steve's fire, here are some numbers from my laptop: > > RX packets:2483405 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2573655 errors:0 dropped:0 overruns:0 carrier:0 > 10:21am up 15 days, 14:09, 6 users, load average: 0.52, 0.47, 0.50 > > Similarly, how often do you expect the WEP key to change? I would > say "never", because it's all manual key management and nobody likes > flag-days. > > I agree that I'd prefer a CBC mode with random explicit IV per packet, > although then you need a decent RNG in your cards. I think the > biggest potential flaw with 802.11 will be new-found XOR attacks. CBC > will fix that completely. > > Honestly what I'd REALLY like to see is real key management, so you > could have an individual encryption key for every user in the system. > One approach is to perform an ephemeral DH per 'pair' of communicating > devices. In infrastructure mode you would perform a key agreement > when you attach to the network and use that for the length of your > session. Before I left Telcordia I even came up with a protocol that > would let you fit this into the existing 802.11 authentication scheme. > Alas, this protocol was left in their hands. > > Steve, I happen to somewhat disagree that real key management would > make the other issues disappear. It would mitigate them a bit, but > not eliminate them. The XOR class of attacks would still exist, > although it might be harder to pull them off. what do you mean by XOR attacks, the plaintext malleability problem of additive encryption? Or have I missed something? thanks, dam > > -derek > > "Steven M. Bellovin" writes: > > > In message > <5.1.0.14.2.20020228085148.0302a628@exna07.securitydynamics.com>, "H > > ousley, Russ" writes: > > > > > > > >The tables associated with the precomputation attacks are > extremely large > > >and unwieldy. I think it is more likely that the keys would be > extracted > > >from an implementation. The assurance of implementations > needs to improve > > >significantly before the effort associated with such a precomputation > > >attack would even be considered by an attacker. > > > > > > > Yes, extracting the keys from an implementation -- due to buggy > > software, a stolen laptop, a disgruntled employee, etc. -- is the > > biggest problem. But the issue that I believe Derek is talking > > about isn't precomputation, it's reuse of a counter. The Borisov/ > > Goldberg/ Wagner paper pointed out that many implementations start > > the variable portion of their counter at 0 each time they're > > power-cycled. This lets me attack the *upstream* traffic from, > > say, a laptop, and the upstream traffic is much more likely to have > > passwords. The attack isn't precomputation, it's XORing two > > ciphertext streams against each other, producing the XOR of two > > plaintext streams -- and that's generally easy to tease apart. > > > > Yes, it's good that the MAC address is part of the counter, since > > that does segregate different traffic sources. But unless another > > portion of the initial counter value is high-quality random, there's > > likely to be trouble, especially given how long keys last in an > > 802.11 environment. > > > > How should the initial counter be constructed? Per Appendix B of > > the NIST spec, we want one portion that is incremented for each > > message, and one portion that is incremented for each block in a > > message. We have 128 bits to play with. MAC addresses are going > > to 8 bytes, which eats up 64 bits. There's a push to increase > > packet sizes to 9K; at 16 bytes/block, we need 10 bits for blocks > > within a packet. That leaves 54 bits. If those 54 are chosen as > > a true-random number, the odds on a collision are 50% in 2^27 > > "sessions". That's acceptable. But we need to figure in the length > > of a session -- that is, how many packets are sent starting with > > some given value. I don't have the time now to work this exactly, > > but (assuming that I'm doing the math right, which is always a > > dicey question when it comes to me doing even slightly complex > > probability calculations) I think we're close to the edge. Let's > > assume, to be safe, that a "session" is 1,000,000 packets, which > > is ~2^20. (That may be too low -- my laptop has been up for a > > week, and it's received 1.6 million packets just on its wired > > interface in that time. VoIP and video will generate long packet > > streams.) If we want to avoid any overlap of the counter space -- > > and we do -- we have 2^34 possible disjoint spaces. By the birthday > > paradox, the probability of a match is about 50% with 2^17 sessions. > > (I'd *really* like it if someone checked my math here...) > > > > Would one laptop have 2^17 sessions of 2^20 packets each? Probably > > not -- at 20 reboots a day (which is a lot even for Windows), it > > would take about 18 years to reach that many. Access points send > > lots of packets, but they aren't power-cycled that often. But it's > > close enough to make me nervous; I've seen enough other parameters > > change by an order of magnitude or more in just a few years. (In > > 1994, I annoyed my wife by insisting that our new PC needed huge > > amounts of disk and RAM -- 500M and 32M.) > > > > What should be done? My preferred answer is to use CBC mode. IV > > collisions there leak information that two packets have a common > > prefix; it says nothing about the contents of the packet, and in > > IPv4 the first block of the IP header will generally differ because > > of the IP "id" field. (We won't get that advantage in IPv6, however, > > and some implementations of v4 use constant "id" fields most of > > the time.) But that's not a critical leakage, compared with counter > > mode where plaintext is leaked. > > > > But the *real* answer is to add key management, in which case none of > > the rest of this matters! > > > > --Steve Bellovin, http://www.research.att.com/~smb > > Full text of "Firewalls" book now at http://www.wilyhacker.com > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From warlord@MIT.EDU Thu Feb 28 15:55:28 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA19351 for ; Thu, 28 Feb 2002 15:55:28 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA08040; Thu, 28 Feb 2002 15:55:24 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA25951; Thu, 28 Feb 2002 15:55:22 -0500 (EST) Received: from x15-cruise-basselope.mit.edu (X15-CRUISE-BASSELOPE.MIT.EDU [18.187.1.60]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id PAA26028; Thu, 28 Feb 2002 15:55:21 -0500 (EST) Received: (from warlord@localhost) by x15-cruise-basselope.mit.edu (8.9.3) id PAA23035; Thu, 28 Feb 2002 15:55:21 -0500 (EST) To: "David A. Mcgrew" Cc: "Housley, Russ" , "Walker, Jesse" , "Vincenzo Liguori" , From: "Derek Atkins" Subject: Re: [saag] RE: AES Counter Mode References: Date: 28 Feb 2002 15:55:20 -0500 In-Reply-To: Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: David, "David A. Mcgrew" writes: > > Steve, I happen to somewhat disagree that real key management would > > make the other issues disappear. It would mitigate them a bit, but > > not eliminate them. The XOR class of attacks would still exist, > > although it might be harder to pull them off. > > what do you mean by XOR attacks, the plaintext malleability problem of > additive encryption? Or have I missed something? What I mean is when you have encryptions where: C1 = P1 xor K1 and C2 = P2 xor K2 If you every find a C1, C2 such that K1 == K2, you can attack the cipher by obtaining the xor of the two plaintexts. > thanks, > > dam -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From mbaugher@cisco.com Thu Feb 28 19:18:02 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA22032 for ; Thu, 28 Feb 2002 19:18:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA25304 for ; Thu, 28 Feb 2002 19:18:01 -0500 (EST) Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g210I0E12429; Thu, 28 Feb 2002 16:18:00 -0800 (PST) Received: from mbaugher-w2k1.cisco.com ([10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id AAZ46006; Thu, 28 Feb 2002 16:16:20 -0800 (PST) Message-Id: <4.3.2.7.2.20020228161316.0954ced8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Feb 2002 16:15:34 -0800 To: "Derek Atkins" From: Mark Baugher Subject: Re: [saag] RE: AES Counter Mode Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > >What I mean is when you have encryptions where: > > C1 = P1 xor K1 >and C2 = P2 xor K2 > >If you every find a C1, C2 such that K1 == K2, you can attack the >cipher by obtaining the xor of the two plaintexts. I believe key management can prevent this. Mark > > thanks, > > > > dam > >-derek > >-- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From plambert@sprintmail.com Fri Mar 1 03:38:22 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id DAA26726 for ; Fri, 1 Mar 2002 03:38:17 -0500 (EST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id DAA24856 for ; Fri, 1 Mar 2002 03:38:16 -0500 (EST) Received: from [192.168.1.100] ([63.205.245.218]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSA00DX7DBRAI@mta7.pltn13.pbi.net> for saag@mit.edu; Fri, 01 Mar 2002 00:38:16 -0800 (PST) Date: Fri, 01 Mar 2002 00:38:10 -0800 From: Paul Lambert Subject: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach In-reply-to: <200202271949.OAA14319@linus.mitre.org> X-Sender: plambert@mail.sprintmail.com To: "Steven M. Christey" Cc: saag@mit.edu Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <200202271949.OAA14319@linus.mitre.org> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: What do people think? I've just recently read your disclosure document that you sent to the list on February 18th and the resulting deluge of discussion. My comments are: 1) this discussion does not belong on the SAAG list a) create a new list (please) b) attempt to get a BOF created if you wish this to be an IETF work item 2) I agree with Ran: A better approach is to move this document to become something >other than an RFC published by someone other than RFC Editor/IETF >and representing whatever that publisher (or applicable community >for that publisher) thinks is appropriate. I noticed that a forum for defining the disclosure process ... the "Organization for Internet Safety" was announced February 22nd: http://news.zdnet.co.uk/story/0,,t269-s2104841,00.html It looks like your document has a good home in this group. Perhaps the discussion on your document could move to a mailing list affiliated with this consortium. As a aside ... The journalist the wrote the press release (above) made the common mistake of assuming that a non-standards track Internet Draft is a meaningful representation of IETF work and also confused an ID with an RFC: "Known as a request for comment, or RFC, the draft guidelines aim to help companies eliminate vulnerabilities, help customers minimise the risk from security flaws, and provide tools for identifying security holes and managing a company's response." Perhaps there is a place in the IETF for a Best Common Practices that would attempt to regulate these unruly reporters :-) All too often transient non-standards track IDs are pushed out in press releases as meaningful representations of Internet consensus. So ... here's a possible abstract this BCP: "Responsible Standards Disclosure Process" Abstract New specifications for software and hardware products are publicized on a daily basis. The disclosure of the status of standards specifications has been a divisive topic for years. During the process of disclosure, many vendors, security researchers, and other parties misrepresent non-standards track specifications. Some parties may be unaware of the IETF process, or they may intentionally ignore them. This state of affairs can make it difficult to achieve a satisfactory outcome for everyone who uses or is affected by specifications. The purpose of this document is to describe best practices for a responsible standards disclosure process that involves technology reporters, product vendors or maintainers, third parties, the security community, and ultimately customers and users. Paul -- From coley@linus.mitre.org Fri Mar 1 04:37:19 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA27298 for ; Fri, 1 Mar 2002 04:37:16 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id EAA00691 for ; Fri, 1 Mar 2002 04:37:16 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g219bF826662; Fri, 1 Mar 2002 04:37:15 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g219bEk12503; Fri, 1 Mar 2002 04:37:14 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id EAA11047; Fri, 1 Mar 2002 04:37:14 -0500 (EST) Date: Fri, 1 Mar 2002 04:37:14 -0500 (EST) Message-Id: <200203010937.EAA11047@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: plambert@sprintmail.com CC: saag@mit.edu Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Paul Lambert said: [various things that have already been covered in this list, plus...] >I noticed that a forum for defining the disclosure process ... the >"Organization for Internet Safety" was announced February 22nd: The co-author of the document, Chris Wysopal, works for one of the companies in OIS. >As a aside ... The journalist the wrote the press release (above) >made the common mistake of assuming that a non-standards track >Internet Draft is a meaningful representation of IETF work and also >confused an ID with an RFC: Both Chris and I have tried to make it very clear to the press what the IETF process is, and the distinction between I-Ds, RFCs, and BCPs, and where this document was in that process, and how even a BCP is not a "standard." Unfortunately, in my experience, it seems that few journalists provide an early copy of the article to the interviewee so that it can be double-checked. Of the interviews I've done, one journalist provided me with an advance copy. The press can make errors that we can't control, and some people aren't likely to read the RFC's that define the IETF process. >Perhaps there is a place in the IETF for a Best Common Practices that >would attempt to regulate these unruly reporters :-) I think that a BCP would be very useful, not only for journalists but for people who are new to the IETF. Chris and I did not know, for example, that we had to contact the SAAG directors before we even proposed the Internet-Draft. I did not see this guidance on the IETF web site. >All too often transient non-standards track IDs are pushed out in >press releases as meaningful representations of Internet consensus. There was no formal "press release" for our draft. The press probably picked up the story from my post to Bugtraq, which explicitly stated that we were proposing an Internet-Draft and not an RFC. Here is the first paragraph: > >An Internet-Draft titled "Responsible Disclosure Process" has been > >released for commentary by me and Chris Wysopal of @stake. This > >Internet-Draft may be reviewed by members of the IETF and the general > >public. This is the first step towards establishing an RFC (Request > >for Comments) and Best Current Practices document. This document is > >*not* an RFC, and it does *not* represent a commitment by the IETF to > >produce an RFC. It is the first step within the IETF review process. I'm not sure how to emphasize the draft's status more clearly. The announcement also included 2 URL's on the IETF and RFC process. We did what we could, given the circumstances and the difficulty of obtaining guidance in much of this process. - Steve From rja@extremenetworks.com Fri Mar 1 09:27:38 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA00137 for ; Fri, 1 Mar 2002 09:27:38 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA17118 for ; Fri, 1 Mar 2002 09:27:38 -0500 (EST) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 5B55267107; Fri, 1 Mar 2002 09:47:42 -0500 (EST) Date: Fri, 1 Mar 2002 09:27:36 -0500 Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: plambert@sprintmail.com, saag@mit.edu To: "Steven M. Christey" From: RJ Atkinson In-Reply-To: <200203010937.EAA11047@linus.mitre.org> Message-Id: <7A408534-2D20-11D6-9A61-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Friday, March 1, 2002, at 04:37 , Steven M. Christey wrote: > > Both Chris and I have tried to make it very clear to the press what > the IETF process is, An alternate, more commonly used, approach is to not engage with the press prematurely, as you indicate above you all did... And that includes not replying to press enquiries if any arise. Ran From mbaugher@cisco.com Fri Mar 1 09:46:45 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA00405 for ; Fri, 1 Mar 2002 09:46:45 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA23786 for ; Fri, 1 Mar 2002 09:46:44 -0500 (EST) Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g21Ekg617359; Fri, 1 Mar 2002 06:46:42 -0800 (PST) Received: from mbaugher-w2k1.cisco.com ([10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id AAZ55241; Fri, 1 Mar 2002 06:45:03 -0800 (PST) Message-Id: <4.3.2.7.2.20020301064210.04a37cc0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Mar 2002 06:44:18 -0800 To: RJ Atkinson From: Mark Baugher Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Cc: saag@mit.edu In-Reply-To: <7A408534-2D20-11D6-9A61-00039357A82A@extremenetworks.com> References: <200203010937.EAA11047@linus.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 09:27 AM 3/1/2002 -0500, RJ Atkinson wrote: >On Friday, March 1, 2002, at 04:37 , Steven M. Christey wrote: >> >>Both Chris and I have tried to make it very clear to the press what >>the IETF process is, > >An alternate, more commonly used, approach is to not engage >with the press prematurely, as you indicate above you all did... >And that includes not replying to press enquiries if any >arise. Members of the press will attend IETF sessions and write what they think they hear. Even a minimal formal statement is probably a good thing. Mark >Ran > >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From tim.polk@nist.gov Fri Mar 1 10:51:47 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA01260 for ; Fri, 1 Mar 2002 10:51:47 -0500 (EST) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA18874 for ; Fri, 1 Mar 2002 10:51:47 -0500 (EST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g21FpbUo010199; Fri, 1 Mar 2002 10:51:38 -0500 (EST) Message-Id: <4.2.0.58.20020301104043.0214f2c0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 01 Mar 2002 10:50:22 -0500 To: "David A. Mcgrew" From: Tim Polk Cc: In-Reply-To: References: <4.2.0.58.20020227111226.020c4630@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [saag] AES extended CBC Mode Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: David, I changed the subject line, since this thread has branched off from AES counter mode... > > We > > expect to update SP 800-38A in 2002 to enhance CBC. In the 2002 > > edition of > > 38A the domain of the CBC mode will be extended to include > > plaintexts whose > > bit lengths are not a multiple of the block size. > >Is this the residual block termination method, or something like it? > >thanks, > >David I must warn you that I am way out of my depth here! I talked to the guys down the hall about our plans. This is what they told me: >The method that we are drafting for extending CBC to messages that do not >consist >of complete blocks is based on the method that is given in RFC 2040, which >in turn >is essentially the "ciphertext stealing" method given in Schneier's book. [Here's where I reveal my limited knowledge.] Are "residual block termination" and "ciphertext stealing" related mechanisms, or are they fundamentally different? Thanks, Tim From mcgrew@cisco.com Fri Mar 1 13:53:28 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA03662 for ; Fri, 1 Mar 2002 13:53:28 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA01762 for ; Fri, 1 Mar 2002 13:53:28 -0500 (EST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g21IrRN01127; Fri, 1 Mar 2002 10:53:27 -0800 (PST) Received: from MCGREWW2K ([10.34.251.98]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAY01440; Fri, 1 Mar 2002 10:49:03 -0800 (PST) From: "David A. Mcgrew" To: "Vincenzo Liguori" Cc: Date: Fri, 1 Mar 2002 10:51:12 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Subject: [saag] RE: AES Counter Mode Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Vincenzo, > -----Original Message----- > From: Vincenzo Liguori [mailto:enzo@ocean-logic.com] > Sent: Wednesday, February 27, 2002 1:40 PM > To: David A. Mcgrew > Cc: saag@mit.edu > Subject: RE: AES Counter Mode > > > > Vincenzo, > > David, thanks for your reply. > > > > .................... > > > > > > My questions are: > > > Is the draft likely to change before approval ? > > > > yes, it is likely to change, see below. Also, the draft is an > individual > > submission, not a working group output. My goal with this draft was to > > create a single counter mode spec that could be used across > multiple IETF > > crypto protocols. I included counter mode as the default cipher > > for secure > > rtp, and the icm draft conforms to that definition. > > > > At present, the consensus on counter mode (among my srtp > > coauthors and other > > that commented on that draft) are that the 128-bit addition that > > is required > > on a per-segment basis by icm is unnecessary and is costlier than > > we'd like. > > The srtp spec will probably be amended slightly by replacing that > > operation > > with XOR, then adding the condition that the lowest 16 bits of the salt > > value are zero. This means that the 'next counter' function is > > still 'plus > > one mod 2^128', but it changes the definition of how the > initial value of > > the counter is established. > > From the implementation point of view XOR is certainly less costly than > an adder. Right. The first impression that I'd had was that a per-packet 128-bit addition was not onerous, and that it would be worthwhile to include that operation in order to gain some flexibility. But the consensus of those that provided feedback is that the simplicity of XOR is significantly better. > > > > > > When is approval likely to be given ? > > > > It's not really up for approval. It's out for comments, and I'd > > be happy to hear yours. If there is sufficient interest in a > > cross-application counter mode spec, then I'll ask about making > it an RFC. > > I'm not really a cryptography expert, my area is more image processing, > but I do a lot of work in implementing algorithms in general in RTL. > So, I cannot really comment of the security aspect. > However, from an implementation point of view I liked that AES counter > mode you proposed seems readily parallelizable and it only used AES in > encryption mode. Since an encryption only AES module with a 128 bit > key (with no key expander) is only about 8K gates with a max throughput > of ~700 Mbit/s in 0.18 u, it follows that it would be easily possible > to support multigigabit applications with a reasonable gate count. > > I also had a look at OCB and it was harder to implement. It also required > AES in both encryption and decryption mode. I don't remember exactly, but > I'm not sure whether it was readily parallelizable. I belive that it is paralellizable. > > > > > ICM can be viewed as a specialization of the NIST suggested CTR > mode (NIST > > Special Publication 800-38A, Recommendation for Block Cipher Modes of > > Operation - Methods and Techniques, online at > > http://csrc.nist.gov/publications/nistpubs/index.html) to packet > > encryption. > > The NIST document describes a counter mode using 128-bit > integer increment > > as the next-counter operation, while icm describes how to use that > > definition to generate keystream segments appropriate for packet > > encryption. > > > > The most important security fact about counter mode is that it should be > > used with a random initial counter. > > True random number in hardware are not too hard to generate. The problem > is convincing the ASIC vendor to accept the exotic circuit that > intentionally > violates all their rules :-) > > > So no matter what spec you end up > > implementing, please keep that in mind :-) > > I wouldn't implement something until it is standard or unless a customer > asks me to. > > > > > > Is there any reference C code available ? > > > > There will be sometime soon, as part of the srtp reference code. > > Thanks again. Is there a way to keep up to date on this ? > Maybe I can join this mailing list if possible. I don't expect to > contribute, > but I list I can follow when consensus is reached. Joining the list is a good idea, http://web.mit.edu/network/ietf/sa/ provides info on how to do it. dam > > > > > dam > > Enzo > > ------------------------------------------------------------------ > Vincenzo Liguori > Ocean Logic Pty Ltd > PO BOX 768 > Manly NSW 1655 > Australia > > Ph : +61-2-99054152 > Fax : +61-2-99050921 > Email : enzo@ocean-logic.com > WWW : http://www.ocean-logic.com > From mcgrew@cisco.com Fri Mar 1 13:22:07 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA03290 for ; Fri, 1 Mar 2002 13:22:01 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25713 for ; Fri, 1 Mar 2002 13:22:01 -0500 (EST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g21ILw623071; Fri, 1 Mar 2002 10:21:58 -0800 (PST) Received: from MCGREWW2K ([10.34.251.98]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAY00486; Fri, 1 Mar 2002 10:17:35 -0800 (PST) From: "David A. Mcgrew" To: "Stephen Kent" , "Steven M. Bellovin" Cc: "Housley, Russ" , "Derek Atkins" , "Walker, Jesse" , "Vincenzo Liguori" , Subject: RE: [saag] RE: AES Counter Mode Date: Fri, 1 Mar 2002 10:19:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > -----Original Message----- > From: saag-admin@mit.edu [mailto:saag-admin@mit.edu]On Behalf Of Stephen > Kent > Sent: Thursday, February 28, 2002 7:44 AM > To: Steven M. Bellovin > Cc: Housley, Russ; Derek Atkins; David A. Mcgrew; Walker, Jesse; > Vincenzo Liguori; saag@mit.edu > Subject: Re: [saag] RE: AES Counter Mode > > > At 10:00 AM -0500 2/28/02, Steven M. Bellovin wrote: > >In message > ><5.1.0.14.2.20020228085148.0302a628@exna07.securitydynamics.com>, "H > >ousley, Russ" writes: > > > >> > >>The tables associated with the precomputation attacks are > extremely large > >>and unwieldy. I think it is more likely that the keys would be extracted > >>from an implementation. The assurance of implementations needs > to improve > >>significantly before the effort associated with such a precomputation > >>attack would even be considered by an attacker. > >> > > > >Yes, extracting the keys from an implementation -- due to buggy > >software, a stolen laptop, a disgruntled employee, etc. -- is the > >biggest problem. But the issue that I believe Derek is talking > >about isn't precomputation, it's reuse of a counter. The Borisov/ > >Goldberg/ Wagner paper pointed out that many implementations start > >the variable portion of their counter at 0 each time they're > >power-cycled. This lets me attack the *upstream* traffic from, > >say, a laptop, and the upstream traffic is much more likely to have > >passwords. The attack isn't precomputation, it's XORing two > >ciphertext streams against each other, producing the XOR of two > >plaintext streams -- and that's generally easy to tease apart. > > > >Yes, it's good that the MAC address is part of the counter, since > >that does segregate different traffic sources. But unless another > >portion of the initial counter value is high-quality random, there's > >likely to be trouble, especially given how long keys last in an > >802.11 environment. > > > >How should the initial counter be constructed? Per Appendix B of > >the NIST spec, we want one portion that is incremented for each > >message, and one portion that is incremented for each block in a > >message. We have 128 bits to play with. MAC addresses are going > >to 8 bytes, which eats up 64 bits. There's a push to increase > >packet sizes to 9K; at 16 bytes/block, we need 10 bits for blocks > >within a packet. That leaves 54 bits. If those 54 are chosen as > >a true-random number, the odds on a collision are 50% in 2^27 > >"sessions". That's acceptable. But we need to figure in the length > >of a session -- that is, how many packets are sent starting with > >some given value. I don't have the time now to work this exactly, > >but (assuming that I'm doing the math right, which is always a > >dicey question when it comes to me doing even slightly complex > >probability calculations) I think we're close to the edge. Let's > >assume, to be safe, that a "session" is 1,000,000 packets, which > >is ~2^20. (That may be too low -- my laptop has been up for a > >week, and it's received 1.6 million packets just on its wired > >interface in that time. VoIP and video will generate long packet > >streams.) If we want to avoid any overlap of the counter space -- > >and we do -- we have 2^34 possible disjoint spaces. By the birthday > >paradox, the probability of a match is about 50% with 2^17 sessions. > >(I'd *really* like it if someone checked my math here...) > > > >Would one laptop have 2^17 sessions of 2^20 packets each? Probably > >not -- at 20 reboots a day (which is a lot even for Windows), it > >would take about 18 years to reach that many. Access points send > >lots of packets, but they aren't power-cycled that often. But it's > >close enough to make me nervous; I've seen enough other parameters > >change by an order of magnitude or more in just a few years. (In > >1994, I annoyed my wife by insisting that our new PC needed huge > >amounts of disk and RAM -- 500M and 32M.) > > > >What should be done? My preferred answer is to use CBC mode. IV > >collisions there leak information that two packets have a common > >prefix; it says nothing about the contents of the packet, and in > >IPv4 the first block of the IP header will generally differ because > >of the IP "id" field. (We won't get that advantage in IPv6, however, > >and some implementations of v4 use constant "id" fields most of > >the time.) But that's not a critical leakage, compared with counter > >mode where plaintext is leaked. > > > >But the *real* answer is to add key management, in which case none of > >the rest of this matters! > > > I concur with Steve's suggestion, i.e., in the IPsec context I would > like to see an IV used with each packet in a CTR mode. Such use also > has a benefit for implementations in which multiple crypto chips are > used to serve a set of subscribers, e.g., POP vs. CPE deployment. The > benefit is that it usually is not feasible to synch per-packet > counters among the chips, and if the counter value is maintained > outside the chips, then the boundary for security evaluation re this > basic crypto function is greatly expanded. One can generate IVs on a > per chip basis and avoid expanding the evaluation boundary. if chip vendors want to use an explicit random iv within counter mode because it solves some problem for their implementations, then adding that as an option to a counter mode spec would be fine. I don't see any technical problems with making that an option. It might also be worth considering that we can eliminate the need for inter-chip synchronization by adding deterministic rather than random data to each packet. Instead of using a random IV within each packet, and relying for security on the improbability of coincidences between those values, we can assign each chip a distinct number and carry this number in the packet instead of the IV. This method allows each chip to maintian a distinct sequence number yet use the same key for all chips. The advantages of using a deterministic approach are that the per-packet data can be half as large, that there's no need to provide a high rate of random data, nor is there the potential weakness that would result from the use of a poor RNG to provide the IVs. Of course, the deterministic approach doesn't satisfy Steve B.'s desire to protect against the 'two time pad' problem that can arise from inadvertent duplicate-key use. dam > > Steve > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag From tytso@thunk.org Fri Mar 1 15:03:18 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA04657 for ; Fri, 1 Mar 2002 15:03:18 -0500 (EST) Received: from thunk.org (THUNK.ORG [216.175.175.175]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA06384; Fri, 1 Mar 2002 15:03:18 -0500 (EST) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.34 #1 (Debian)) id 16gtFK-0000qa-00; Fri, 01 Mar 2002 15:03:14 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16gtFH-0000v7-00; Fri, 01 Mar 2002 15:03:11 -0500 Date: Fri, 1 Mar 2002 15:03:11 -0500 From: Theodore Tso To: "Steven M. Christey" Cc: plambert@sprintmail.com, saag@mit.edu Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Message-ID: <20020301150311.C2971@thunk.org> References: <200203010937.EAA11047@linus.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <200203010937.EAA11047@linus.mitre.org>; from coley@linus.mitre.org on Fri, Mar 01, 2002 at 04:37:14AM -0500 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Fri, Mar 01, 2002 at 04:37:14AM -0500, Steven M. Christey wrote: > I think that a BCP would be very useful, not only for journalists but > for people who are new to the IETF. Chris and I did not know, for > example, that we had to contact the SAAG directors before we even > proposed the Internet-Draft. I did not see this guidance on the IETF > web site. As I understand what happened, I believe the issue was that you refused to give a draft copy to the security area directors because you wanted to do some "industry consultation" first. (Which in the IETF culture, brings to mind a back-door, smoke-filled room sort of process.) The document then leaked to a reporter, who then asked a security area director to comment on something that he hadn't seen yet, despite his request to get a draft copy earlier. I would hope that it doesn't require guidance on the IETF web site for it to be clear that a reporter should be able to get access to a draft before the AD..... That's all water under the bridge, but I do perceive a certain amount of irony, in that while you were trying to author a paper which has as a presupposition that it is possible for "the good guys" to keep something a secret for even a short amount of time, you weren't able to keep the text of that document from leaking to the press during roughly the same time period. As the saying goes, "Three peoeple can keep a secret --- if two of them are dead." I also like the aphorism (which I first saw from a Tom Clancy book), that the probability of a secret being blown is equal to the *square* of the number of people who are in on it. - Ted From cwysopal@atstake.com Fri Mar 1 15:48:13 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA05272 for ; Fri, 1 Mar 2002 15:48:13 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id PAA24122 for ; Fri, 1 Mar 2002 15:48:12 -0500 (EST) Received: (qmail 399 invoked from network); 1 Mar 2002 20:50:44 -0000 Received: from softdnserror (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 1 Mar 2002 20:50:44 -0000 Received: from atstake.com (ssh-gw.atstake.com [63.168.6.76]) by cam-relay.atstake.com (Postfix) with SMTP id 8693E2281C; Fri, 1 Mar 2002 15:46:41 -0500 (EST) Message-ID: <3C7FE8A8.4090601@atstake.com> Date: Fri, 01 Mar 2002 15:46:32 -0500 From: Chris Wysopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Theodore Tso Cc: "Steven M. Christey" , plambert@sprintmail.com, saag@mit.edu Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach References: <200203010937.EAA11047@linus.mitre.org> <20020301150311.C2971@thunk.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Theodore Tso wrote: > As I understand what happened, I believe the issue was that you > refused to give a draft copy to the security area directors because > you wanted to do some "industry consultation" first. (Which in the > IETF culture, brings to mind a back-door, smoke-filled room sort of > process.) The document then leaked to a reporter, who then asked a > security area director to comment on something that he hadn't seen > yet, despite his request to get a draft copy earlier. What happened was we asked people to review the document before we submitted it to the IETF. The list of reviewers is included in the document. These people are from a wide array of positions within the security community. It would be hard to categorize this as a smoke-filled room meeting. We sought reviewers from the vendor, coordinator, and reporter communities. To wit: 6 Acknowledgements We gratefully acknowledge the constructive comments received from several contributors. Any errors or inconsistencies in this document are solely the responsibility of the authors, and not of the reviewers. This document does not necessarily reflect the opinion of the reviewers or their parent organizations. We would like to thank Andy Balinsky, Mary Ann Davidson, Elias Levy, Russ Cooper, Scott Blake, Seth Arnold, Rain Forest Puppy, Marcus Ranum, Lori Woeler, Adam Shostack, Mark Loveless, Scott Culp, and Shawn Hernan for their valuable input. > I would hope that it doesn't require guidance on the IETF web site for > it to be clear that a reporter should be able to get access to a draft > before the AD..... > > That's all water under the bridge, but I do perceive a certain amount > of irony, in that while you were trying to author a paper which has as > a presupposition that it is possible for "the good guys" to keep > something a secret for even a short amount of time, you weren't able > to keep the text of that document from leaking to the press during > roughly the same time period. Of course we did not give the document to a reporter. On the other hand we didn't think the document was so critical, as 0 day vulnerability information often is, that we had to have our reviewers treat it as a state secret. -Chris > - Ted > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > From Weimer@CERT.Uni-Stuttgart.DE Fri Mar 1 15:56:49 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA05387 for ; Fri, 1 Mar 2002 15:56:49 -0500 (EST) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id PAA27660 for ; Fri, 1 Mar 2002 15:56:48 -0500 (EST) Received: (qmail 2172 invoked by uid 1000); 1 Mar 2002 20:49:57 -0000 To: Chris Wysopal Cc: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea References: <3C79E93E.20905@nomadiclab.com> <3C7A6C09.1060802@atstake.com> From: Florian Weimer Date: Fri, 01 Mar 2002 21:49:57 +0100 In-Reply-To: <3C7A6C09.1060802@atstake.com> (Chris Wysopal's message of "Mon, 25 Feb 2002 08:53:29 -0800") Message-ID: <874rk0qah6.fsf@CERT.Uni-Stuttgart.DE> Lines: 17 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Chris Wysopal writes: > Currently in the industry there IS rough consensus on the issue. Really? I think quite a few contracts covering software licenses explicitly frobid customers to follow the proposed process, so there's certainly NOT consensus. There is a lot of software which is used in the corporate sector which is completely below the radar of the security community at large. Do you think that's because this software hasn't got any security problems? -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From Weimer@CERT.Uni-Stuttgart.DE Fri Mar 1 16:26:35 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA05780 for ; Fri, 1 Mar 2002 16:26:34 -0500 (EST) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id QAA11422 for ; Fri, 1 Mar 2002 16:26:23 -0500 (EST) Received: (qmail 2831 invoked by uid 1000); 1 Mar 2002 21:19:32 -0000 To: "Hallam-Baker, Phillip" Cc: saag@mit.edu Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea References: <2F3EC696EAEED311BB2D009027C3F4F405869990@vhqpostal.verisign.com> From: Florian Weimer Date: Fri, 01 Mar 2002 22:19:32 +0100 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869990@vhqpostal.verisign.com> ("Hallam-Baker, Phillip"'s message of "Wed, 27 Feb 2002 07:55:22 -0800") Message-ID: <87vgcgoujf.fsf@CERT.Uni-Stuttgart.DE> Lines: 29 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Hallam-Baker, Phillip" writes: > I think that Ron has hit upon a good suggestion. The whole thesis underlying > full disclosure is that it leads to modification of vendor behavior. We have > much more direct means available to affect vendor behavior. > > Perhaps we could modify the CERT process to report the number of security > issues outstanding against a given vendor. Vendor or product? Neither works. CERT/CC information is largely based on vendor information and often misleading, sometimes even wrong. For example, many vendors do not care at all about products which are officially unsupported but still used in the field. Such products usually do not appear on the CERT/CC website, or not with sufficient detail. Vendors are sometimes wrong when judging the impact of a vulnerability. Vendors release vulnerable product upgrades weeks after they have claimed that their original product is not vulnerable (and release a fixed version months later). That's why a reasonable amount of disclosure is needed. We do not want to have an indicator of how much confidence we should have in a vendor, we want to check that the vendor's claims are correct. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From smb@research.att.com Fri Mar 1 16:35:39 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA05930 for ; Fri, 1 Mar 2002 16:35:35 -0500 (EST) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA06388 for ; Fri, 1 Mar 2002 16:31:51 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 6682E4CEF5 for ; Fri, 1 Mar 2002 16:31:51 -0500 (EST) Received: from berkshire.research.att.com (sigaba.research.att.com [135.207.23.169]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id QAA24237 for ; Fri, 1 Mar 2002 16:27:57 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 6602F7B4B for ; Fri, 1 Mar 2002 16:31:47 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: saag@mit.edu Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Mar 2002 16:31:47 -0500 Message-Id: <20020301213147.6602F7B4B@berkshire.research.att.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: For another perspective, see http://www.research.att.com/~smb/papers/draft-ymbk-obscurity-00.txt by Randy Bush and myself. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From crawdad@gungnir.fnal.gov Fri Mar 1 16:55:53 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA06151 for ; Fri, 1 Mar 2002 16:55:53 -0500 (EST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA23159 for ; Fri, 1 Mar 2002 16:55:53 -0500 (EST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GSB0046GE95HT@smtp.fnal.gov> for saag@mit.edu; Fri, 01 Mar 2002 15:55:53 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g21LtqZ11541 for ; Fri, 01 Mar 2002 15:55:52 -0600 (CST) Date: Fri, 01 Mar 2002 15:55:52 -0600 From: Matt Crawford Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach In-reply-to: "01 Mar 2002 15:03:11 EST." <20020301150311.C2971@thunk.org> To: saag@mit.edu Message-id: <200203012155.g21LtqZ11541@gungnir.fnal.gov> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Here's the thought that occurred to me when I first began reading this document (which, by the way, I detest). I didn't want to inject my bad attitude then, but I may as well now, since it won't make things any worse. How different would this document be if it had been produced by security-concious end-users rather than these soi-disant "coordinators"? Very. From svh@cert.org Fri Mar 1 17:01:40 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA06297 for ; Fri, 1 Mar 2002 17:01:40 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA24652 for ; Fri, 1 Mar 2002 17:01:40 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.69) with ESMTP id RAA15050 for ; Fri, 1 Mar 2002 17:01:39 -0500 (EST) Received: from firstbase.blue.cert.org (firstbase.blue.cert.org [10.10.10.45]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.8) with ESMTP id RAA26867 for ; Fri, 1 Mar 2002 17:01:37 -0500 (EST) Date: Fri, 1 Mar 2002 17:01:39 -0500 Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: "Shawn V. Hernan" To: saag@mit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20020301213147.6602F7B4B@berkshire.research.att.com> Message-Id: X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Friday, March 1, 2002, at 04:31 PM, Steven M. Bellovin wrote: > http://www.research.att.com/~smb/papers/draft-ymbk-obscurity-00.txt > Playing devil's advocate for a moment, I say an assertion that something is true, even an assertion that goes back more than 100 years, does not make it so. That disclosure is a good thing is not axiomatic. Despite the dogma that secrets are *necessarily* short-lived, there are plenty of counterexamples. None of which should be confused for my personal opinion on the subject, btw. I especially like the phrase "The IETF supports and encourages the open but prudent discussion of vulnerabilities in hardware and software in all appropriate IETF venues." Shawn From Weimer@CERT.Uni-Stuttgart.DE Fri Mar 1 17:05:13 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA06367 for ; Fri, 1 Mar 2002 17:05:13 -0500 (EST) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id RAA17937 for ; Fri, 1 Mar 2002 17:05:12 -0500 (EST) Received: (qmail 6093 invoked by uid 1000); 1 Mar 2002 21:58:21 -0000 To: "Hallam-Baker, Phillip" Cc: saag@mit.edu Subject: Re: [saag] Re: Internet-Draft for "Responsible Disclosure Process " released References: <2F3EC696EAEED311BB2D009027C3F4F405869971@vhqpostal.verisign.com> From: Florian Weimer Date: Fri, 01 Mar 2002 22:58:20 +0100 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869971@vhqpostal.verisign.com> ("Hallam-Baker, Phillip"'s message of "Mon, 25 Feb 2002 10:29:28 -0800") Message-ID: <874rk0osqr.fsf@CERT.Uni-Stuttgart.DE> Lines: 23 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Hallam-Baker, Phillip" writes: > There is certainly a point where 'full disclosure' starts to become close to > the mode of cracking favored by elite hackers who do not use the virus or > other exploit code themselves but make it available to as many lamers as > possible. A few companies also have something close to a business interest that vulnerabilities are actually exploited. Some of their products and services wouldn't sell if software was secure. It seems to me that some players have conflicting interests. For example, a Microsoft-blessed security company asked us once to give them an exploit they assumed we had developed, with rather questionable justification. Is it responsible to promote the circulation of exploit code in this way? It's not just the underground which is problematic. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From cwysopal@atstake.com Fri Mar 1 17:12:22 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA06550 for ; Fri, 1 Mar 2002 17:12:22 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id RAA20896 for ; Fri, 1 Mar 2002 17:12:22 -0500 (EST) Received: (qmail 1233 invoked from network); 1 Mar 2002 22:14:53 -0000 Received: from softdnserror (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 1 Mar 2002 22:14:53 -0000 Received: from atstake.com (ssh-gw.atstake.com [63.168.6.76]) by cam-relay.atstake.com (Postfix) with SMTP id 3CAFC22817; Fri, 1 Mar 2002 17:12:10 -0500 (EST) Message-ID: <3C7FFCB0.1090605@atstake.com> Date: Fri, 01 Mar 2002 17:12:00 -0500 From: Chris Wysopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Steven M. Bellovin" Cc: saag@mit.edu Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach References: <20020301213147.6602F7B4B@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Steven M. Bellovin wrote: > For another perspective, see > http://www.research.att.com/~smb/papers/draft-ymbk-obscurity-00.txt > by Randy Bush and myself. This is not another perspective. The whole point of a the disclosure process I-D is to make sure it happens. If there are problems with the process that unduly restrict disclosure they should be fixed. >2. Revealing Vulnerabilities is Useful > > Revealing and discussing vulnerabilities in hardware and software > products allows the users to protect themselves, and encourages > general protection and repair strategies. > > On the other hand, there is a well-established culture of giving the > manufacturer of the vulnerable product a short but reasonable early > warning of discovered vulnerabilities so that they have an > opportunity to repair them and or prepare to distribute patches or > work-arounds. Furthermore, it is better if developers have time to > test their patches; much of the current mess comes from inadequate > software testing. The disclosure process I-D documents this so that newcomers don't have to learn the unwritten cultural rules and have a ready guide. It is this culture that needs to be documented. > The IETF supports and encourages the open but prudent discussion of > vulnerabilities in hardware and software in all appropriate IETF > venues. Some see the glass half full with the disclosure process I-D and others see it half empty. Many fail to disclose and discuss vulnerabilities publically for fear for their jobs or fear they will get sued. A BCP can promote disclosure better than simple language saying that it is useful. It is critical, much like whistleblower protections, to get people to speak publically when working within risk averse environments. Not everyone has the publication luxury of an academic or independant. -Chris > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > From cwysopal@atstake.com Fri Mar 1 17:26:12 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA06754 for ; Fri, 1 Mar 2002 17:26:12 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id RAA26096 for ; Fri, 1 Mar 2002 17:26:12 -0500 (EST) Received: (qmail 1336 invoked from network); 1 Mar 2002 22:28:43 -0000 Received: from softdnserror (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 1 Mar 2002 22:28:43 -0000 Received: from atstake.com (ssh-gw.atstake.com [63.168.6.76]) by cam-relay.atstake.com (Postfix) with SMTP id 3B8DE22817; Fri, 1 Mar 2002 17:24:24 -0500 (EST) Message-ID: <3C7FFF8F.4080505@atstake.com> Date: Fri, 01 Mar 2002 17:24:15 -0500 From: Chris Wysopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Matt Crawford Cc: saag@mit.edu Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach References: <200203012155.g21LtqZ11541@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Matt Crawford wrote: > How different would this document be if it had been produced > by security-concious end-users rather than these soi-disant > "coordinators"? Neither Steve Christey nor I are coordinators. I represent the reporter category. I have researched and published a half dozen advisories. As an employee of a security company my primary concern is the security of my customers, who make up the end-user category. Steve Christey is a security researcher who was instrumental in the creation of the Mitre CVE. CVE does not do any coordination. It is a database of known vulnerabilities. -Chris From hilarie@xmission.com Fri Mar 1 19:12:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA07892 for ; Fri, 1 Mar 2002 19:12:35 -0500 (EST) Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA23254 for ; Fri, 1 Mar 2002 19:12:34 -0500 (EST) Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16gx8b-0006qG-00 for saag@mit.edu; Fri, 01 Mar 2002 17:12:33 -0700 Received: from shell.xmission.com ([198.60.22.20] helo=xmission.xmission.com) by mail.xmission.com with esmtp (Exim 3.22 #1) id 16gx8b-0002AB-00 for saag@mit.edu; Fri, 01 Mar 2002 17:12:33 -0700 Received: from hilarie by xmission.xmission.com with local (Exim 3.16 #3) id 16gx8b-00022x-00 for saag@mit.edu; Fri, 01 Mar 2002 17:12:33 -0700 From: "Hilarie Orman, Purple Streak Development" To: saag@mit.edu Message-Id: Date: Fri, 01 Mar 2002 17:12:33 -0700 Subject: [saag] Re: BCP for reporting on IDs ... Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > I especially like the phrase "The IETF supports and encourages the > open but prudent discussion of vulnerabilities in hardware and software > in all appropriate IETF venues." I'd like it better if it read: "The IETF supports and encourages the use of its open venues for prudent discussions of hardware and software vulnerabilities." But literary history shows us that it is always more impressive to use snippets of foreign language than to write clearly in one's native language. Although the IETF didn't invent Authority Through Obscurity, it sure has a lot of ardent believers. Nothing personal in this disclosure - it is only one example. Perhaps it will cause a panic in the writer community as they all race to clean up their prose. Hilarie From OgleR@thmulti.com Fri Mar 1 21:32:52 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id VAA09266 for ; Fri, 1 Mar 2002 21:32:52 -0500 (EST) Received: from ns1.thmulti.com (ns1.thmulti.com [141.11.234.67]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA15078 for ; Fri, 1 Mar 2002 21:32:51 -0500 (EST) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id DAA28704; Sat, 2 Mar 2002 03:32:49 +0100 (MET) Received: from parexch3.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id DAA15126; Sat, 2 Mar 2002 03:32:49 +0100 (MET) Received: by parexch3 with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Mar 2002 03:32:51 +0100 Message-ID: <05B4910E0216D411B14F00508B6A67A9029419F6@RENEXCH5.rennes.thmulti.com> From: "Ogle Ron (Rennes)" To: "'Florian Weimer'" , "Hallam-Baker, Phillip" Cc: saag@mit.edu Subject: RE: [saag] The Responsible Disclosure draft: A Bad Idea Date: Sat, 2 Mar 2002 03:32:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Two intentions to my original posting. First and foremost is to try to move vendors into designing and developing better products. I know it's kind of like the tail wagging the dog, but vulnerabilities disclosure is the tail end not the head. Second, there needs to be some way to pay mutual respect between the reporter and the vendor. If the vendor seems to be doing an honest and fair job towards security, then shouldn't we help them instead of trying to bash their brains. I mean most vendors don't want their names published on the news about security problems. On the other hand, if the vendor isn't cooperating (given historical data), then everything is fair game. I just thought that there could be a set of levels that could differentiate the levels of cooperation and/or practices by the vendor. Of course, if the vulnerability becomes public, then the vendor becomes a secondary thought and the general public should have priority to find the fix. (I would think that a vendor who truly cared about security would announce the vulnerability out themselves even if they didn't have a fix if a vulnerability becomes wild before they are ready.) Ron Ogle Rennes, France > -----Original Message----- > From: Florian Weimer [mailto:Weimer@CERT.Uni-Stuttgart.DE] > Sent: Friday, March 01, 2002 10:20 PM > To: Hallam-Baker, Phillip > Cc: saag@mit.edu > Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea ... > That's why a reasonable amount of disclosure is needed. We do not > want to have an indicator of how much confidence we should have in a > vendor, we want to check that the vendor's claims are correct. > > -- > Florian Weimer Weimer@CERT.Uni-Stuttgart.DE > University of Stuttgart > http://CERT.Uni-Stuttgart.DE/people/fw/ > RUS-CERT +49-711-685-5973/fax > +49-711-685-5898 > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > From OgleR@thmulti.com Fri Mar 1 22:02:42 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id WAA09532 for ; Fri, 1 Mar 2002 22:02:41 -0500 (EST) Received: from ns1.thmulti.com (ns1.thmulti.com [141.11.234.67]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA27457 for ; Fri, 1 Mar 2002 22:02:41 -0500 (EST) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id EAA29169; Sat, 2 Mar 2002 04:02:40 +0100 (MET) Received: from parexch9.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id EAA15444; Sat, 2 Mar 2002 04:02:39 +0100 (MET) Received: by outlook.paris.thmulti.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Mar 2002 04:02:44 +0100 Message-ID: <05B4910E0216D411B14F00508B6A67A9029419F7@RENEXCH5.rennes.thmulti.com> From: "Ogle Ron (Rennes)" To: "'Chris Wysopal'" , Matt Crawford , "Steven M. Christey" Cc: saag@mit.edu Subject: RE: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Date: Sat, 2 Mar 2002 04:02:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: It would seem that Steve Christey in actuality should be working for the good of the US because in some way his work is probably being funded by either the US DoD (probably the Air Force), DARPA, or NSF. Mitre is a Federally Funded Research and Development Center that is mostly paid through DoD (normally the Air Force) projects. Because there is so much distrust in the group, maybe Steve should state if Mitre is paying for this or if he's doing this on his own. If Mitre is paying the nickel, then we should understand why. Mitre normally doesn't pay for these types of things out of over head. Normally there is a project sponsor behind the work. If the sponsor is the DoD or NSF as I suspect, then I would hope that there is more trust in the group that Steve isn't on the vendor's payroll. Steve? We can understand your company's motivation for paying you to work on this, Chris. It's just very suspicious that @Stake and Microsoft have been seen together. FUD is among us (wait a minute isn't this what Microsoft preaches?). My .02 Euro cent piece. Ron Ogle Rennes, France > -----Original Message----- > From: Chris Wysopal [mailto:cwysopal@atstake.com] > Sent: Friday, March 01, 2002 11:24 PM > To: Matt Crawford > Cc: saag@mit.edu > Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure > draft: an alternate approach ... > Neither Steve Christey nor I are coordinators. I represent > the reporter > category. I have researched and published a half dozen > advisories. As > an employee of a security company my primary concern is the > security of > my customers, who make up the end-user category. > > Steve Christey is a security researcher who was instrumental in the > creation of the Mitre CVE. CVE does not do any coordination. > It is a > database of known vulnerabilities. > > -Chris From plambert@sprintmail.com Fri Mar 1 23:38:42 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA10416 for ; Fri, 1 Mar 2002 23:38:42 -0500 (EST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA09304 for ; Fri, 1 Mar 2002 23:38:41 -0500 (EST) Received: from [192.168.1.100] ([64.172.181.0]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSB00DF2WWGAB@mta7.pltn13.pbi.net> for saag@mit.edu; Fri, 01 Mar 2002 20:38:41 -0800 (PST) Date: Fri, 01 Mar 2002 20:38:35 -0800 From: Paul Lambert Subject: responsible-disclosure@yahoogroups.com -> was Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach In-reply-to: <200203010937.EAA11047@linus.mitre.org> X-Sender: plambert@mail.sprintmail.com To: "Steven M. Christey" Cc: saag@mit.edu, responsible-disclosure@yahoogroups.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Lp6pJtiV/LVxPfG196sOtA)" References: <200203010937.EAA11047@linus.mitre.org> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: --Boundary_(ID_Lp6pJtiV/LVxPfG196sOtA) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT At 4:37 AM -0500 3/1/02, Steven M. Christey wrote: >Paul Lambert said: > >[various things that have already been covered in this list, plus...] Yes ... including that this is the wrong mailing list for this topic! So ... I've started a new list: Group name : responsible-disclosure Group home page : http://groups.yahoo.com/group/responsible-disclosure Group email : responsible-disclosure@yahoogroups.com There is now an alternate forum for this discussion. I'll gladly give full administrative privileges to the first person or two that asks. Paul -- --Boundary_(ID_Lp6pJtiV/LVxPfG196sOtA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT responsible-disclosure@yahoogroups.com -> was Re: BCP


At 4:37 AM -0500 3/1/02, Steven M. Christey wrote:
Paul Lambert said:

[various things that have already been covered in this list, plus...]

Yes ... including that this is the wrong mailing list for this topic!  So ... I've started a new list:

Group name :
responsible-disclosure

Group home page :
http://groups.yahoo.com/group/responsible-disclosure

Group email :
responsible-disclosure@yahoogroups.com
There is now an alternate forum for this discussion.  I'll gladly give full administrative privileges to the first person or two that asks.





Paul


--
--Boundary_(ID_Lp6pJtiV/LVxPfG196sOtA)-- From smb@research.att.com Fri Mar 1 23:59:41 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id XAA10612 for ; Fri, 1 Mar 2002 23:59:41 -0500 (EST) Received: from berkshire.research.att.com (bgp421284bgs.union01.nj.comcast.net [68.36.179.91]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA11642 for ; Fri, 1 Mar 2002 23:59:40 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id A58187B4B for ; Fri, 1 Mar 2002 23:59:36 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: saag@mit.edu Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Mar 2002 23:59:36 -0500 Message-Id: <20020302045936.A58187B4B@berkshire.research.att.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >We can understand your company's motivation for paying you to work on this, >Chris. It's just very suspicious that @Stake and Microsoft have been seen >together. FUD is among us (wait a minute isn't this what Microsoft >preaches?). Can we all stop name-calling and focus on the issues? People may or may not have hidden motives; that's irrelevant to the worth of the arguments. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From aleph1@securityfocus.com Sat Mar 2 04:12:09 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA12846 for ; Sat, 2 Mar 2002 04:12:09 -0500 (EST) From: aleph1@securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [66.38.151.9]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id EAA25140 for ; Sat, 2 Mar 2002 04:12:08 -0500 (EST) Received: (qmail 27014 invoked by uid 101); 2 Mar 2002 09:09:57 -0000 Date: Sat, 2 Mar 2002 02:09:57 -0700 To: Paul Lambert Cc: "Steven M. Christey" , saag@mit.edu, responsible-disclosure@yahoogroups.com Subject: Re: responsible-disclosure@yahoogroups.com -> was Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Message-ID: <20020302090957.GE28794@securityfocus.com> References: <200203010937.EAA11047@linus.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: * Paul Lambert (plambert@sprintmail.com) [020302 04:52]: > > Yes ... including that this is the wrong mailing list for this topic! > So ... I've started a new list: > > Group name : > responsible-disclosure > Group home page : > http://groups.yahoo.com/group/responsible-disclosure > Group email : > > responsible-disclosure@yahoogroups.com > > There is now an alternate forum for this discussion. I'll gladly give > full administrative privileges to the first person or two that asks. Disappointing choice in name and description (on the web site). It implies there is only one "responsible" disclosure process. > > Paul > > -- -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum From coley@linus.mitre.org Sat Mar 2 13:12:55 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA17445 for ; Sat, 2 Mar 2002 13:12:55 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA01864 for ; Sat, 2 Mar 2002 13:12:54 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g22ICs823884; Sat, 2 Mar 2002 13:12:54 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g22ICok10111; Sat, 2 Mar 2002 13:12:50 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id NAA11498; Sat, 2 Mar 2002 13:12:50 -0500 (EST) Date: Sat, 2 Mar 2002 13:12:50 -0500 (EST) Message-Id: <200203021812.NAA11498@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: plambert@sprintmail.com CC: saag@mit.edu Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: First of all, I must note that the IETF home page does not have a "press" link, which is commonly used by entities that receive media attention. > As I understand what happened, I believe the issue was that you > refused to give a draft copy to the security area directors because > you wanted to do some "industry consultation" first. We did not refuse to give the directors a draft copy. We were not the ones who leaked it to the press. We were working on a draft copy with the intention of ironing out the bugs before making a draft public, so that the draft would be less controversial. The original document that we had written would have generated much more attention and controversy than the draft we published. >The document then leaked to a reporter, who then asked a security area >director to comment on something that he hadn't seen yet, despite his >request to get a draft copy earlier. This is slightly inaccurate. We were not contacted by the director until the press went to him. We then sent what we had THE SAME DAY AS WE RECEIVED THE REQUEST. We always had full intentions to contact the area directors for guidance once we had something that we believed we could make public. But the press was made aware of an early copy and went to the directors themselves. BTW, we tried to explain all this in to SAAG in December: http://jis.mit.edu/pipermail/saag/2001q4/000358.html One person responded, nobody questioned whether it should be a BCP at the time, nobody followed up with further press guidance or pointers, and we were not informed of any discussions that took place in the SAAG meeting at that time. That email includes the following: We humbly suggest that the "Considerations for Internet Drafts" page at http://www.ietf.org/ID-nits.html could be modified to discourage such behind-the-scenes creation of a draft without notifying the IETF first. For example, one comment says "Individual submissions (whether general or to a working group) may be made without prior notice." We fully intended to find and notify the appropriate IETF authorities before submitting an Internet-Draft. The interesting phrase is "SUBMISSIONS MAY BE MADE WITHOUT PRIOR NOTICE" (emphasis mine). >(Which in the IETF culture, brings to mind a back-door, smoke-filled >room sort of process.) We have run into several instances of "IETF culture" in which the rules are not made clear to outsiders, but the rules aren't documented anywhere, either. It therefore should not be surprising when outsiders with the best of intentions still somehow violate these rules. It also should not be surprising that when those outsiders do not receive feedback when they explicitly request it, they might make mistakes when they move forward. For example, several of our emails received no response. >That's all water under the bridge Until someone else violates the same unwritten rules and is labeled a troublemaker as a result, possibly undermining otherwise valid technical work. - Steve P.S. My frustration is not due to SAAG's reaction to the I-D itself. I'm a big boy and I can handle that. But it was very frustrating to even get to a draft stage, and we've taken a beating on some of the very things we've asked for guidance on, or for which there is no guidance. From coley@linus.mitre.org Sat Mar 2 13:59:58 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA17962 for ; Sat, 2 Mar 2002 13:59:58 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA08475 for ; Sat, 2 Mar 2002 13:59:58 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g22Ixv825983 for ; Sat, 2 Mar 2002 13:59:58 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g22Ixuk12610 for ; Sat, 2 Mar 2002 13:59:56 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id NAA16436; Sat, 2 Mar 2002 13:59:56 -0500 (EST) Date: Sat, 2 Mar 2002 13:59:56 -0500 (EST) Message-Id: <200203021859.NAA16436@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: RE: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Ogle Ron (Rennes)" said: >It would seem that Steve Christey in actuality should be working for >the good of the US because in some way his work is probably being >funded by either the US DoD (probably the Air Force), DARPA, or NSF. >Mitre is a Federally Funded Research and Development Center that is >mostly paid through DoD (normally the Air Force) projects. Ah, an opportunity to clear things up! Thank you. From http://www.mitre.org/about/ : In partnership with government clients, MITRE is a not-for-profit corporation working in the public interest. It addresses issues of critical national importance, combining systems engineering and information technology to develop innovative solutions that make a difference. MITRE's work is focused within three Federally Funded Research and Development Centers (FFRDCs). One FFRDC performs systems engineering and integration work for Department of Defense C3I. A second performs systems research and development work for the Federal Aviation Administration and other civil aviation authorities. The third FFRDC provides strategic, technical and program management advice to the Internal Revenue Service and the Treasury Department. I am working on disclosure in part as an effort to serve the public interest, and in part because other MITRE work that I do is affected by disclosure. The division that I work in is part of the DoD center. The bulk of my current work is with the CVE vulnerability naming standard (http://cve.mitre.org/about/), which is supported or used by an international cross-section of organizations across the security community. While I don't have any previous experience with the IETF outside of my "Infinite Monkey Protocol Suite" April Fools RFC, I do have some experience in trying to build consensus between a variety of people in an open environment as the Chair of the CVE Editorial Board (http://cve.mitre.org/board/). >Maybe Steve should state if Mitre is paying for this or if he's doing >his on his own. My disclosure efforts are being paid for out of a combination of CVE project funds and my personal time. CVE is directly affected by vulnerability disclosure. For example, if reporters and vendors don't coordinate with each other, there is an increased risk that duplicate CVE items are created (and this does happen, unfortunately). If vendors don't acknowledge vulnerabilities, there is typically less confidence that the issue is real [1]. If the reporter doesn't work with the vendor, they may diagnose the problem incorrectly or only see the tip of the iceberg, leading to further inaccuracy. As we move towards distributing portions of the CVE "name space" to other parties known as Candidate Numbering Authorities, it has become clear that "responsible disclosure" (for some definition of "responsible") needs to be encouraged [2]. There are some current discussions regarding the impact of vague vendor advisories on CVE. - Steve References ---------- [1] "[TECH] Analysis of vendor acknowledgement according to CVE" http://cve.mitre.org/board/archives/2000-09/msg00038.html [2] "Discussion of Candidate Numbering Authorities (CNAs)" http://cve.mitre.org/board/archives/2001-07/msg00000.html From crawdad@gungnir.fnal.gov Mon Mar 4 10:11:12 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA12260 for ; Mon, 4 Mar 2002 10:11:11 -0500 (EST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA04810 for ; Mon, 4 Mar 2002 10:11:11 -0500 (EST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GSG00IN0FINZZ@smtp.fnal.gov> for saag@mit.edu; Mon, 04 Mar 2002 09:11:11 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g24FBAZ06750 for ; Mon, 04 Mar 2002 09:11:10 -0600 (CST) Date: Mon, 04 Mar 2002 09:11:10 -0600 From: Matt Crawford Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach In-reply-to: "01 Mar 2002 17:24:15 EST." <3C7FFF8F.4080505@atstake.com> To: saag@mit.edu Message-id: <200203041511.g24FBAZ06750@gungnir.fnal.gov> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > As an employee of a security company my primary concern is the > security of my customers, who make up the end-user category. ^ INSERT: a small fraction of From svh@cert.org Mon Mar 4 18:50:42 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA19583 for ; Mon, 4 Mar 2002 18:50:41 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA13270 for ; Mon, 4 Mar 2002 18:50:41 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.69) with ESMTP id SAA08478; Mon, 4 Mar 2002 18:50:35 -0500 (EST) Received: from firstbase.blue.cert.org (firstbase.blue.cert.org [10.10.10.45]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.9) with ESMTP id SAA01664; Mon, 4 Mar 2002 18:50:35 -0500 (EST) Date: Mon, 4 Mar 2002 18:50:37 -0500 Subject: Re: BCP for reporting on IDs was -> Re: [saag] Disclosure draft: an alternate approach Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Shawn V. Hernan" , plambert@sprintmail.com, "Steven M. Christey" To: saag@mit.edu From: "Shawn V. Hernan" In-Reply-To: <200203021812.NAA11498@linus.mitre.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Saturday, March 2, 2002, at 01:12 PM, Steven M. Christey wrote: > We were working on a draft copy with the intention of ironing out the > bugs before making a draft public, so that the draft would be less > controversial. As one of the early reviewers, I can attest to this. It was presented to me with exactly the motivation the Steve describes. There are no smoke-filled rooms to be wary of here. Shawn From svh@cert.org Mon Mar 4 19:11:26 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA19847 for ; Mon, 4 Mar 2002 19:11:26 -0500 (EST) Received: from beniaminus.red.cert.org (beniaminus.red.cert.org [192.88.209.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA19832 for ; Mon, 4 Mar 2002 19:11:26 -0500 (EST) Received: from smtp.indigo.cert.org (smtp.indigo.cert.org [192.88.209.150]) by beniaminus.red.cert.org (8.9.3/8.9.3/1.69) with ESMTP id TAA10778; Mon, 4 Mar 2002 19:11:22 -0500 (EST) Received: from firstbase.blue.cert.org (firstbase.blue.cert.org [10.10.10.45]) by smtp.indigo.cert.org (8.9.3/8.9.3/2.9) with ESMTP id TAA02686; Mon, 4 Mar 2002 19:11:21 -0500 (EST) Date: Mon, 4 Mar 2002 19:11:23 -0500 Subject: Re: [saag] The Responsible Disclosure draft: A Bad Idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Shawn V. Hernan" , "Hallam-Baker, Phillip" To: saag@mit.edu, Florian Weimer From: "Shawn V. Hernan" In-Reply-To: <87vgcgoujf.fsf@CERT.Uni-Stuttgart.DE> Message-Id: <86F98C8A-2FCD-11D6-9BC1-0050E4E0B060@cert.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Friday, March 1, 2002, at 04:19 PM, Florian Weimer wrote: > Neither works. CERT/CC information is largely based on vendor > information and often misleading, sometimes even wrong. For example, > many vendors do not care at all about products which are officially > unsupported but still used in the field. Without wishing to engage in an extended discussion of how CERT determines what to publish (although you are free to followup to me directly if you like -- I don't want to waste SAAG's time with this) , I will say a couple of things. To the best of our ability, we publish what we believe to be true, either through direct testing, corroborating testimony, empirical observation, or other methods. The vulnerabilities we choose to publish on are generally those we judge to be the most serious, according to a metric that we have employed for a number of years. That some products reach end-of-life with existing vulnerabilities is certainly true. See for example http://www.cert.org/advisories/CA-2002-06.html#lucent. Whose responsibility is it to deal with these orphans? We have never made any claim that there should be a single voice for security information. Indeed, I believe that would be most unhealthy for the community, and unhealthy for us. > We do not > want to have an indicator of how much confidence we should have in a > vendor, we want to check that the vendor's claims are correct. > Verification is always a good thing, IMHO. The Internet, and the scientific process, rely on informal but effective checks and balances, without which progress is impossible. But ultimately there must be some point to it. Do you want to check the veracity of vendors' claims merely to shake an accusatory finger when they're wrong? This is very much off-topic, so I won't post further about this topic to this group. Anyone who wishes to follow up with me is welcome to. Shawn From enzo@ocean-logic.com Tue Mar 5 06:10:41 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id GAA26687 for ; Tue, 5 Mar 2002 06:10:40 -0500 (EST) Received: from mail016.syd.optusnet.com.au (mail016.syd.optusnet.com.au [203.2.75.176]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id GAA19794 for ; Tue, 5 Mar 2002 06:10:39 -0500 (EST) Received: from co3001263a (c40190.belrs1.nsw.optusnet.com.au [203.164.13.82]) by mail016.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id g25BAY616849; Tue, 5 Mar 2002 22:10:34 +1100 From: "Vincenzo Liguori" To: "David A. Mcgrew" Cc: Date: Tue, 5 Mar 2002 22:10:51 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Subject: [saag] RE: AES Counter Mode Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > Vincenzo, > ................ > > > one mod 2^128', but it changes the definition of how the > > initial value of > > > the counter is established. > > > > From the implementation point of view XOR is certainly less costly than > > an adder. > > Right. The first impression that I'd had was that a per-packet 128-bit > addition was not onerous, and that it would be worthwhile to include that > operation in order to gain some flexibility. But the consensus of those > that provided feedback is that the simplicity of XOR is significantly > better. XOR certainly has faster propagation delay and lower gate count than an adder. However, the advantage of using AES in encryption mode only rather than both encryption and decryption is much more significant (see below). > > .............. > > I also had a look at OCB and it was harder to implement. It > also required > > AES in both encryption and decryption mode. I don't remember > exactly, but > > I'm not sure whether it was readily parallelizable. > > I belive that it is paralellizable. Sure, however counter mode requires AES in encryption mode only for both encryption and decryption whereas OCB needs AES in decryption mode during decryption (at least that was my understanding of the spec). This is a fairly significant saving in hardware. In fact an AES core supporting both encryption and decryption is normally 2 times the size of an encryption only core. By sharing as much logic as we could we went down to 12.4 Kgates (~1.5 times the size of encryption only) with no key expander. The core is also slightly slower. OCB also requires extra control, etc. So, provided that counter mode is safe enough, its implementation is a *lot* simpler than OCB. This is purely from the hardware implementation point of view : as I said already, I don't feel qualified enough to comment about safety aspects. > ......... > Joining the list is a good idea, http://web.mit.edu/network/ietf/sa/ > provides info on how to do it. > > dam > Enzo ------------------------------------------------------------------ Vincenzo Liguori Ocean Logic Pty Ltd PO BOX 768 Manly NSW 1655 Australia Ph : +61-2-99054152 Fax : +61-2-99050921 > > Email : enzo@ocean-logic.com WWW : http://www.ocean-logic.com From mls00420@attbi.com Sun Mar 17 15:03:48 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA22501 for ; Sun, 17 Mar 2002 15:03:48 -0500 (EST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA25543 for ; Sun, 17 Mar 2002 15:03:48 -0500 (EST) Received: from danky ([12.228.126.233]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020317200347.YCTF2951.rwcrmhc53.attbi.com@danky> for ; Sun, 17 Mar 2002 20:03:47 +0000 Message-ID: <003601c1cdee$b5ba98e0$0301a8c0@attbi.com> From: "Matthew L Scott" To: Date: Sun, 17 Mar 2002 12:02:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C1CDAB.A764FE40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [saag] Books for SAAG Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C1CDAB.A764FE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, My name is Matthew Scott and I have been in the networking industry for = a couple of years after graduating in 2000 with a degree in Applied = Math. I am interested in becoming more involved in this workgroup, and = I was wondering what books you can recommend. Thanks and have a great = day. Thanks, Matt ------=_NextPart_000_0033_01C1CDAB.A764FE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
My name is Matthew Scott and I have been in the = networking=20 industry for a couple of years after graduating in 2000 with a degree in = Applied=20 Math.  I am interested in becoming more involved in this workgroup, = and I=20 was wondering what books you can recommend.  Thanks and have a = great=20 day.
 
Thanks,
 
Matt
------=_NextPart_000_0033_01C1CDAB.A764FE40-- From pete.chown@skygate.co.uk Mon Mar 18 05:46:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id FAA26876 for ; Mon, 18 Mar 2002 05:46:18 -0500 (EST) Received: from lion.skygate.co.uk (lion.skygate.co.uk [212.134.128.34]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id FAA08799 for ; Mon, 18 Mar 2002 05:46:17 -0500 (EST) Received: from hyena.skygate.co.uk ([10.0.0.2]) by lion.skygate.co.uk with esmtp (Exim 3.33 #1) id 16muec-00089T-00 for saag@mit.edu; Mon, 18 Mar 2002 10:46:15 +0000 Subject: Re: [saag] Books for SAAG From: Pete Chown To: saag@mit.edu In-Reply-To: <003601c1cdee$b5ba98e0$0301a8c0@attbi.com> References: <003601c1cdee$b5ba98e0$0301a8c0@attbi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Mar 2002 10:46:14 +0000 Message-Id: <1016448375.25250.59.camel@hyena.skygate.co.uk> Mime-Version: 1.0 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Matthew L Scott wrote: > My name is Matthew Scott and I have been in the networking industry > for a couple of years after graduating in 2000 with a degree in > Applied Math. I am interested in becoming more involved in this > workgroup, and I was wondering what books you can recommend. You could try Ross Anderson's Security Engineering, and Alfred Menezes' Handbook of Applied Cryptography. The first book talks about security in a broad sense, the second focuses on crypto specifically. (If your speciality is applied maths you will probably find crypto a bit of a culture shock. Remember those group theory courses that you were so keen to drop... ;-) ) If you want to help with IETF standardisation, you really need to join a working group. This list is for coordinating the IETF's security work but it doesn't usually work directly on Internet standards. -- Pete From coley@linus.mitre.org Mon Mar 18 13:43:26 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA00402 for ; Mon, 18 Mar 2002 13:43:26 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA07418 for ; Mon, 18 Mar 2002 13:43:25 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g2IIhP817578 for ; Mon, 18 Mar 2002 13:43:25 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g2IIhNk07193 for ; Mon, 18 Mar 2002 13:43:24 -0500 (EST) Received: (from coley@localhost) by linus.mitre.org (8.9.3/8.9.3) id NAA28772; Mon, 18 Mar 2002 13:43:23 -0500 (EST) Date: Mon, 18 Mar 2002 13:43:23 -0500 (EST) Message-Id: <200203181843.NAA28772@linus.mitre.org> X-Authentication-Warning: linus.mitre.org: coley set sender to coley@linus.mitre.org using -f From: "Steven M. Christey" To: saag@mit.edu Subject: [saag] Withdrawal of "Responsible Disclosure Process" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: All, Chris Wysopal and I are withdrawing the Internet-Draft for "Responsible Vulnerability Disclosure Process" from consideration by the IETF. Based on comments from the SAAG list, there are enough SAAG members who believe that this document is "out of scope" since it does not deal with technical protocols. There does not appear to be any way to achieve consensus on that issue, regardless of the merits of the current draft or any future document that may attempt to describe disclosure recommendations. We are currently identifying other forums that may be more suitable for discussion of the current document and future revisions. If we can't find such a forum, we will create one. If you have suggestions beyond those that have already been mentioned on the SAAG list, please contact me. Despite the ultimate outcome and the procedural difficulties that we encountered along the way, thank you for allowing this discussion to take place within SAAG. A number of issues have been raised that we need to address, and future documents will be improved as a result of the comments that we have received from SAAG and elsewhere. We only hope that we can find or create another forum that matches the IETF in terms of open discussion, consensus building, international scope, and credibility. Regards, Steve From pbaker@verisign.com Mon Mar 25 13:14:14 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA24059 for ; Mon, 25 Mar 2002 13:14:14 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA12923 for ; Mon, 25 Mar 2002 13:14:13 -0500 (EST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g2PIAXO02248 for ; Mon, 25 Mar 2002 10:10:33 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 10:15:27 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A2F@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: saag@mit.edu Date: Mon, 25 Mar 2002 10:15:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D428.FFDCDF10" Subject: [saag] Security Advisor Council Proposal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D428.FFDCDF10 Content-Type: text/plain; charset="iso-8859-1" Just thought it might be appropriate to put into words what I tried to say at the IETF SAAG but might not have come across right due to lack of time to be more precise. I think that in general most of the working groups are concerned about the security aspects of their protocols. The problem as I see it is not that people don't care about security, or even that they are unaware of the security implications, the problems more often lie in failing to asses properly the level of risk and the effectiveness of the solutions. For example, Digest Authentication in HTTP was not deployed until six years after it was proposed and then only because of the IESG fiat that protocols could not use passwords in the clear as their only security mechanism. The group understood that sending passowrds in the clear was not a good idea, however the need to store the password in encrypted form was considered to be the overriding security priority. This type of behavior is also to be seen in 802.11b (and I strongly suspect Bluetooth). The group decides that the security issue is 'Wired Equivalent Privacy' and all security proposals are going to be measured against that standard. The issues of integrity and access control are essentially foreclosed before the design begins. The fact that WEP also botched the crypto is actually irrelevant as the original security spec is broken as designed from the standpoint of enterprise deployment. Another set of pathologies come from groups who build a risk model and then insist upon a particular design even if it is operationally infeasible. A group will fixate on a particular aspect of a security design even though it has significant costs and provides no real security advantage. A prime example of this is protocols that use digital signatures in place of a MAC in order to provide for 'non-repudiation'. Non-repudiation is fine and usefull of course, but it is completely irrelevant if the applications are not expected to save the messages for later analysis or pass them on to some other party. What is going to be needed is a more systematic and structured approach to writing security considerations sections in RFCs. At the moment those sections are often no more than a list of potential exploits. What I would like to see appearing is an analysis that is akin to a requirements analysis but cast in security terms: What are the asserts that we are protecting? What additional assets does our protocol architecture introduce? What are the potential risks that those assets might be subject to? What are the specific threats that are present in the described architecture? What controls are implemented to mitigate those risks/threats? What is the level of residual risk? Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C1D428.FFDCDF10 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1D428.FFDCDF10-- From rja@extremenetworks.com Mon Mar 25 14:29:57 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA25304 for ; Mon, 25 Mar 2002 14:29:57 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA26032 for ; Mon, 25 Mar 2002 14:29:57 -0500 (EST) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 4AB3867103; Mon, 25 Mar 2002 14:53:28 -0500 (EST) Date: Mon, 25 Mar 2002 14:29:53 -0500 Subject: Re: [saag] Security Advisor Council Proposal Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: saag@mit.edu To: "Hallam-Baker, Phillip" From: RJ Atkinson In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869A2F@vhqpostal.verisign.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Monday, March 25, 2002, at 01:15 , Hallam-Baker, Phillip wrote: > What is going to be needed is a more systematic and structured approach to > writing security considerations sections in RFCs. At the moment those > sections are often no more than a list of potential exploits. What I would > like to see appearing is an analysis that is akin to a requirements > analysis > but cast in security terms: > > What are the asserts that we are protecting? > What additional assets does our protocol architecture introduce? > What are the potential risks that those assets might be subject to? > What are the specific threats that are present in the described > architecture? > What controls are implemented to mitigate those risks/threats? > What is the level of residual risk? After the last IAB Security Workshop (some years back now), I wrote up guidelines on Security Considerations as an I-D. That I-D got wedged (for reasons that I never figured out) in the IESG of that time. Subsequently, Eric Rescorla has been running with that I-D, making edits of his own along the way. With luck that document will eventually become an RFC later this year. Ran rja@extremenetworks.com From rgm-sec@htt-consult.com Mon Mar 25 16:33:54 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA27208 for ; Mon, 25 Mar 2002 16:33:53 -0500 (EST) Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id QAA26497 for ; Mon, 25 Mar 2002 16:33:51 -0500 (EST) Received: from port3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Mon, 25 Mar 2002 16:33:53 -0500 Message-Id: <5.1.0.14.2.20020325163120.02d63b88@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 16:33:46 -0500 To: saag@mit.edu From: Robert Moskowitz In-Reply-To: References: <2F3EC696EAEED311BB2D009027C3F4F405869A2F@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: Subject: [saag] FWD: 1024-bit RSA keys in danger of compromise Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm >List-Id: >List-Post: >List-Help: >List-Unsubscribe: >List-Subscribe: >Delivered-To: mailing list bugtraq@securityfocus.com >Delivered-To: moderator for bugtraq@securityfocus.com >X-envelope-info: >From: "Lucky Green" >To: >Subject: 1024-bit RSA keys in danger of compromise >Date: Sat, 23 Mar 2002 17:38:02 -0800 >Organization: Cypherpunks Jihad > >As those of you who have discussed RSA keys size requirements with me >over the years will attest to, I always held that 1024-bit RSA keys >could not be factored by anyone, including the NSA, unless the opponent >had devised novel improvements to the theory of factoring large >composites unknown in the open literature. I considered this to be >possible, but highly unlikely. In short, I believed that users' desires >for keys larger than 1024-bits were mostly driven by a vague feeling >that "larger must be better" in some cases, and by downright paranoia in >other cases. I was mistaken. > >Based upon requests voiced by a number of attendees to this year's >Financial Cryptography conference , I assembled and >moderated a panel titled "RSA Factoring: Do We Need Larger Keys?". The >panel explored the implications of Bernstein's widely discussed >"Circuits for Integer Factorization: a Proposal". >http://cr.yp.to/papers.html#nfscircuit > >Although the full implications of the proposal were not necessarily >immediately apparent in the first few days following Bernstein's >publication, the incremental improvements to parts of NFS outlined in >the proposal turn out to carry significant practical security >implications impacting the overwhelming majority of deployed systems >utilizing RSA or DH as the public key algorithms. > >Coincidentally, the day before the panel, Nicko van Someren announced at >the FC02 rump session that his team had built software which can factor >512-bit RSA keys in 6 weeks using only hardware they already had in the >office. > >A very interesting result, indeed. (While 512-bit keys had been broken >before, the feasibility of factoring 512-bit keys on just the computers >sitting around an office was news at least to me). > >The panel, consisting of Ian Goldberg and Nicko van Someren, put forth >the following rough first estimates: > >While the interconnections required by Bernstein's proposed architecture >add a non-trivial level of complexity, as Bruce Schneier correctly >pointed out in his latest CRYPTOGRAM newsletter, a 1024-bit RSA >factoring device can likely be built using only commercially available >technology for a price range of several hundred million dollars to about >1 billion dollars. Costs may well drop lower if one has the use of a >chip fab. It is a matter of public record that the NSA as well as the >Chinese, Russian, French, and many other intelligence agencies all >operate their own fabs. > >Some may consider a price tag potentially reaching $1B prohibitive. One >should keep in mind that the NRO regularly launches SIGINT satellites >costing close to $2B each. Would the NSA have built a device at less >than half the cost of one of their satellites to be able to decipher the >interception data obtained via many such satellites? The NSA would have >to be derelict of duty to not have done so. > >Bernstein's machine, once built, will have power requirements in the MW >to operate, but in return will be able to break a 1024-bit RSA or DH key >in seconds to minutes. Even under the most optimistic estimates for >present-day PKI adoption, the inescapable conclusion is that the NSA, >its major foreign intelligence counterparts, and any foreign commercial >competitors provided with commercial intelligence by their national >intelligence services have the ability to break on demand any and all >1024-bit public keys. > >The security implications of a practical breakability of 1024-bit RSA >and DH keys are staggering, since of the following systems as currently >deployed tend to utilize keys larger than 1024-bits: > >- HTTPS >- SSH >- IPSec >- S/MIME >- PGP > >An opponent capable of breaking all of the above will have access to >virtually any corporate or private communications and services that are >connected to the Internet. > >The most sensible recommendation in response to these findings at this >time is to upgraded your security infrastructure to utilize 2048-bit >user keys at the next convenient opportunity. Certificate Authorities >may wish to investigate larger keys as appropriate. Some CA's, such as >those used to protect digital satellite content in Europe, have already >moved to 4096-bit root keys. > >Undoubtedly, many vendors and their captive security consultants will >rush to publish countless "reasons" why nobody is able to build such a >device, would ever want to build such a device, could never obtain a >sufficient number of chips for such a device, or simply should use that >vendor's "unbreakable virtual onetime pad" technology instead. > >While the latter doesn't warrant comment, one question to ask >spokespersons pitching the former is "what key size is the majority of >your customers using with your security product"? Having worked in this >industry for over a decade, I can state without qualification that >anybody other than perhaps some of the HSM vendors would be misinformed >if they claimed that the majority - or even a sizable minority - of >their customers have deployed key sizes larger than 1024-bits through >their organization. Which is not surprising, since many vendor offerings >fail to support larger keys. > >In light of the above, I reluctantly revoked all my personal 1024-bit >PGP keys and the large web-of-trust that these keys have acquired over >time. The keys should be considered compromised. The revoked keys and my >new keys are attached below. > >--Lucky Green > >-----BEGIN PGP PUBLIC KEY BLOCK----- >Version: PGP 7.1 >Comment: Problems decrypting this email? Upgrade from PGP 1.x/2.x! > >mQGiBDQ1KMERBADzEw3bXeWGt7u7VcYPYtiXmOsEkgN48BB2DbC4+I0oepSNl6wb > > I cut out the key to reduce message size...... Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From Weimer@CERT.Uni-Stuttgart.DE Mon Mar 25 17:32:47 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA28042 for ; Mon, 25 Mar 2002 17:32:47 -0500 (EST) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id RAA17072 for ; Mon, 25 Mar 2002 17:32:47 -0500 (EST) Received: (qmail 11825 invoked by uid 1000); 25 Mar 2002 22:30:08 -0000 To: Robert Moskowitz Cc: saag@mit.edu Subject: Re: [saag] FWD: 1024-bit RSA keys in danger of compromise References: <2F3EC696EAEED311BB2D009027C3F4F405869A2F@vhqpostal.verisign.com> <5.1.0.14.2.20020325163120.02d63b88@localhost> From: Florian Weimer Date: Mon, 25 Mar 2002 23:30:08 +0100 In-Reply-To: <5.1.0.14.2.20020325163120.02d63b88@localhost> (Robert Moskowitz's message of "Mon, 25 Mar 2002 16:33:46 -0500") Message-ID: <874rj4p9fz.fsf@CERT.Uni-Stuttgart.DE> Lines: 17 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Robert Moskowitz writes: > >Bernstein's machine, once built, will have power requirements in the MW > >to operate, but in return will be able to break a 1024-bit RSA or DH key > >in seconds to minutes. This is just FUD. Dan Bernstein's request for an NSF grant leaves the question unanswered whether keys upto ~1500 bits can be tackled today. The asymptotics say nothing about small numbers such as these. The cited article is a DoS attack on the OpenPGP web of trust, and nothing more. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From rhousley@rsasecurity.com Mon Mar 25 18:05:59 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA28557 for ; Mon, 25 Mar 2002 18:05:58 -0500 (EST) Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id SAA13729 for ; Mon, 25 Mar 2002 18:05:58 -0500 (EST) Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for FORT-POINT-STATION.MIT.EDU [18.7.7.76]) with SMTP; 25 Mar 2002 23:05:12 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA03574 for ; Mon, 25 Mar 2002 18:05:10 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2PN5xG27490 for ; Mon, 25 Mar 2002 18:05:59 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 18:03:39 -0500 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.58]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1KZJV; Mon, 25 Mar 2002 18:03:33 -0500 From: "Housley, Russ" To: Robert Moskowitz Cc: saag@mit.edu Message-Id: <5.1.0.14.2.20020325180449.031b2aa8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 18:05:36 -0500 Subject: Re: [saag] FWD: 1024-bit RSA keys in danger of compromise In-Reply-To: <5.1.0.14.2.20020325163120.02d63b88@localhost> References: <2F3EC696EAEED311BB2D009027C3F4F405869A2F@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: From Ian Goldberg: Lucky Green wrote: >The panel, consisting of Ian Goldberg and Nicko van Someren, put forth >the following rough first estimates: I'd just like to credit the "O(minutes)" calculation to Nicko; my own opinion was that: - We have no reason to believe the asymptotic result applies to "real" keylengths (2^1024 <<< infinity) - The physical properties of such a machine (size, power, cooling, etc.) seem implausible to me. I personally don't intend to be revoking my 1024 bit key at this time. - Ian At 04:33 PM 3/25/2002 -0500, Robert Moskowitz wrote: > >Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm > >List-Id: > >List-Post: > >List-Help: > >List-Unsubscribe: > >List-Subscribe: > >Delivered-To: mailing list bugtraq@securityfocus.com > >Delivered-To: moderator for bugtraq@securityfocus.com > >X-envelope-info: > >From: "Lucky Green" > >To: > >Subject: 1024-bit RSA keys in danger of compromise > >Date: Sat, 23 Mar 2002 17:38:02 -0800 > >Organization: Cypherpunks Jihad > > > >As those of you who have discussed RSA keys size requirements with me > >over the years will attest to, I always held that 1024-bit RSA keys > >could not be factored by anyone, including the NSA, unless the opponent > >had devised novel improvements to the theory of factoring large > >composites unknown in the open literature. I considered this to be > >possible, but highly unlikely. In short, I believed that users' desires > >for keys larger than 1024-bits were mostly driven by a vague feeling > >that "larger must be better" in some cases, and by downright paranoia in > >other cases. I was mistaken. > > > >Based upon requests voiced by a number of attendees to this year's > >Financial Cryptography conference , I assembled and > >moderated a panel titled "RSA Factoring: Do We Need Larger Keys?". The > >panel explored the implications of Bernstein's widely discussed > >"Circuits for Integer Factorization: a Proposal". > >http://cr.yp.to/papers.html#nfscircuit > > > >Although the full implications of the proposal were not necessarily > >immediately apparent in the first few days following Bernstein's > >publication, the incremental improvements to parts of NFS outlined in > >the proposal turn out to carry significant practical security > >implications impacting the overwhelming majority of deployed systems > >utilizing RSA or DH as the public key algorithms. > > > >Coincidentally, the day before the panel, Nicko van Someren announced at > >the FC02 rump session that his team had built software which can factor > >512-bit RSA keys in 6 weeks using only hardware they already had in the > >office. > > > >A very interesting result, indeed. (While 512-bit keys had been broken > >before, the feasibility of factoring 512-bit keys on just the computers > >sitting around an office was news at least to me). > > > >The panel, consisting of Ian Goldberg and Nicko van Someren, put forth > >the following rough first estimates: > > > >While the interconnections required by Bernstein's proposed architecture > >add a non-trivial level of complexity, as Bruce Schneier correctly > >pointed out in his latest CRYPTOGRAM newsletter, a 1024-bit RSA > >factoring device can likely be built using only commercially available > >technology for a price range of several hundred million dollars to about > >1 billion dollars. Costs may well drop lower if one has the use of a > >chip fab. It is a matter of public record that the NSA as well as the > >Chinese, Russian, French, and many other intelligence agencies all > >operate their own fabs. > > > >Some may consider a price tag potentially reaching $1B prohibitive. One > >should keep in mind that the NRO regularly launches SIGINT satellites > >costing close to $2B each. Would the NSA have built a device at less > >than half the cost of one of their satellites to be able to decipher the > >interception data obtained via many such satellites? The NSA would have > >to be derelict of duty to not have done so. > > > >Bernstein's machine, once built, will have power requirements in the MW > >to operate, but in return will be able to break a 1024-bit RSA or DH key > >in seconds to minutes. Even under the most optimistic estimates for > >present-day PKI adoption, the inescapable conclusion is that the NSA, > >its major foreign intelligence counterparts, and any foreign commercial > >competitors provided with commercial intelligence by their national > >intelligence services have the ability to break on demand any and all > >1024-bit public keys. > > > >The security implications of a practical breakability of 1024-bit RSA > >and DH keys are staggering, since of the following systems as currently > >deployed tend to utilize keys larger than 1024-bits: > > > >- HTTPS > >- SSH > >- IPSec > >- S/MIME > >- PGP > > > >An opponent capable of breaking all of the above will have access to > >virtually any corporate or private communications and services that are > >connected to the Internet. > > > >The most sensible recommendation in response to these findings at this > >time is to upgraded your security infrastructure to utilize 2048-bit > >user keys at the next convenient opportunity. Certificate Authorities > >may wish to investigate larger keys as appropriate. Some CA's, such as > >those used to protect digital satellite content in Europe, have already > >moved to 4096-bit root keys. > > > >Undoubtedly, many vendors and their captive security consultants will > >rush to publish countless "reasons" why nobody is able to build such a > >device, would ever want to build such a device, could never obtain a > >sufficient number of chips for such a device, or simply should use that > >vendor's "unbreakable virtual onetime pad" technology instead. > > > >While the latter doesn't warrant comment, one question to ask > >spokespersons pitching the former is "what key size is the majority of > >your customers using with your security product"? Having worked in this > >industry for over a decade, I can state without qualification that > >anybody other than perhaps some of the HSM vendors would be misinformed > >if they claimed that the majority - or even a sizable minority - of > >their customers have deployed key sizes larger than 1024-bits through > >their organization. Which is not surprising, since many vendor offerings > >fail to support larger keys. > > > >In light of the above, I reluctantly revoked all my personal 1024-bit > >PGP keys and the large web-of-trust that these keys have acquired over > >time. The keys should be considered compromised. The revoked keys and my > >new keys are attached below. > > > >--Lucky Green > > > >-----BEGIN PGP PUBLIC KEY BLOCK----- > >Version: PGP 7.1 > >Comment: Problems decrypting this email? Upgrade from PGP 1.x/2.x! > > > >mQGiBDQ1KMERBADzEw3bXeWGt7u7VcYPYtiXmOsEkgN48BB2DbC4+I0oepSNl6wb > > > > >I cut out the key to reduce message size...... > >Robert Moskowitz >TruSecure Corporation >Security Interest EMail: rgm-sec@htt-consult.com > >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From gaus@cisco.com Tue Mar 26 03:11:10 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id DAA04875 for ; Tue, 26 Mar 2002 03:11:10 -0500 (EST) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id DAA01617 for ; Tue, 26 Mar 2002 03:11:09 -0500 (EST) Received: from DRAJNOVI-W2K1.cisco.com (drajnovi-isdn-home.cisco.com [10.49.135.250]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16462 for ; Tue, 26 Mar 2002 09:11:08 +0100 (MET) Message-Id: <4.3.2.7.2.20020326080740.05b1b7e0@144.254.74.238> X-Sender: drajnovi@144.254.74.238 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Mar 2002 08:11:07 +0000 To: saag@mit.edu From: Damir Rajnovic Subject: Re: [saag] Security Advisor Council Proposal In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869A2F@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 10:15 25/03/2002 -0800, Hallam-Baker, Phillip wrote: >What are the asserts that we are protecting? > What additional assets does our protocol architecture introduce? >What are the potential risks that those assets might be subject to? >What are the specific threats that are present in the described >architecture? >What controls are implemented to mitigate those risks/threats? >What is the level of residual risk? In addition to that I would like to see the intended modes of usage and an environment. These things are implicit in your questions here but I think it will be worth to spell them out. Once you change your operating environment or use whatever-it-is for purpose not intended, some of your risk assessment will be wrong. Gaus ============== Damir Rajnovic , PSIRT Incident Manager, Cisco Systems Telephone: +44 7715 546 033 200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB ============== There is no insolvable problems. The question is can you accept the solution? From rja@extremenetworks.com Tue Mar 26 10:28:15 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA11431 for ; Tue, 26 Mar 2002 10:28:15 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA19351 for ; Tue, 26 Mar 2002 10:28:14 -0500 (EST) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 701AC67103; Tue, 26 Mar 2002 10:51:53 -0500 (EST) Date: Tue, 26 Mar 2002 10:27:41 -0500 Subject: Re: [saag] Security Advisor Council Proposal Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: saag@mit.edu To: Damir Rajnovic From: RJ Atkinson In-Reply-To: <4.3.2.7.2.20020326080740.05b1b7e0@144.254.74.238> Message-Id: <0314028E-40CE-11D6-BA0C-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Tuesday, March 26, 2002, at 03:11 , Damir Rajnovic wrote: > In addition to that I would like to see the intended modes of usage > and an environment. In the IETF context, "environment" always is the Global Internet. Ran From OgleR@thmulti.com Wed Mar 27 08:46:26 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA06192 for ; Wed, 27 Mar 2002 08:46:26 -0500 (EST) Received: from ns1.thmulti.com (ns1.thmulti.com [141.11.234.67]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA25560 for ; Wed, 27 Mar 2002 08:46:18 -0500 (EST) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id OAA23581; Wed, 27 Mar 2002 14:46:05 +0100 (MET) Received: from parexch9.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id OAA09041; Wed, 27 Mar 2002 14:45:52 +0100 (MET) Received: by outlook.paris.thmulti.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 14:46:06 +0100 Message-ID: <05B4910E0216D411B14F00508B6A67A902941A6D@RENEXCH5.rennes.thmulti.com> From: "Ogle Ron (Rennes)" To: "'Hallam-Baker, Phillip'" , saag@mit.edu Subject: RE: [saag] Security Advisor Council Proposal Date: Wed, 27 Mar 2002 14:46:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I was just writing something similar to my colleagues about a specific domain, consumer electronics, because the US Government is threatening to step into the digital rights arena. I too believe that people do want security; they just don't know how to get it or what is appropriate. In my case, the US Government doesn't know how to achieve or measure it (protection of digital content), but they want it. I think that you want the same. To this goal, I proposed creating a protection profile for consumer electronics. I think that this same solution (or more appropriately a way to achieve a solution) could be used for protocols. I think that we need a way for protocol designers to validate their security effectiveness against the environments that they intend to operate. The SAAG could define a protection profile for other protocols so that at least the right questions get asked over and over again. The protection profile could even define a grading criteria for security principles. This way the rest of the world of developers who may want to use a particular protocol would know what to expect or not expect from a security prospective. My ~.02 (Euro < US) Ron Ogle Rennes, France > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Monday, March 25, 2002 07:15 PM > To: saag@mit.edu > Subject: [saag] Security Advisor Council Proposal > > > Just thought it might be appropriate to put into words what I > tried to say > at the IETF SAAG but might not have come across right due to > lack of time to > be more precise. > > > I think that in general most of the working groups are > concerned about the > security aspects of their protocols. The problem as I see it > is not that > people don't care about security, or even that they are unaware of the > security implications, the problems more often lie in failing to asses > properly the level of risk and the effectiveness of the solutions. > ........ > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > From jns@digitalisland.net Wed Mar 27 15:57:24 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id PAA13112 for ; Wed, 27 Mar 2002 15:57:24 -0500 (EST) Received: from chef.digisle.com (chef.digisle.com [167.216.152.38]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA07567 for ; Wed, 27 Mar 2002 15:57:23 -0500 (EST) Received: from JSTEWARTLT (JSTEWART-LT.digisle.com [172.19.8.13]) by chef.digisle.com (8.9.3/8.9.3) with SMTP id UAA19315; Wed, 27 Mar 2002 20:56:17 GMT Reply-To: From: "John N. Stewart" To: "'Hallam-Baker, Phillip'" , Subject: RE: [saag] Security Advisor Council Proposal Date: Wed, 27 Mar 2002 12:55:41 -0800 Message-ID: <010a01c1d5d1$c1ce52d0$0b0813ac@digisle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869A2F@vhqpostal.verisign.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phill: I'd like to play back to what I took out of this, to see if I read it correctly, and then ponder an idea related to how we approached developing products over the years. If I read your proposal correctly, the weakness is that by leveraging previously bad works, ignorance (the good definition), or just a clean miss in understanding the issues, there are areas of both proposal and development that address security incorrectly. With that in mind, if it is doesn't surface to the right audience, security will be accepted or implemented incorrectly in standards bodies. If nothing else, that is wasteful. - -- In an effort to address this, some methodology whereby security aspects of new or modified areas are scrutinized by good people, in the hopes of lowering this wasteful set of efforts as well as ideally bolster the security aspects for a given protocol or specification. In that vein, either through callouts in the design spec or a review forum of sorts - the requirements and the answers are put to the test. In our product development lifecycle, and in other ones and previous ones I've used, an approach is to have a callout section in the spec that asks and answers those questions. It makes reviewing just those aspects simpler. I hope this re-engages the dialogue. - --j This message and any files or text attached to it are intended only for the recipients named above, and contain information that may be confidential or privileged. If you are not an intended recipient, you must not read, copy, use or disclose this communication. Please also notify the sender by replying to this me. >-----Original Message----- >From: saag-admin@mit.edu [mailto:saag-admin@mit.edu]On Behalf Of >Hallam-Baker, Phillip >Sent: Monday, March 25, 2002 10:15 AM >To: saag@mit.edu >Subject: [saag] Security Advisor Council Proposal > > >Just thought it might be appropriate to put into words >what I tried to say >at the IETF SAAG but might not have come across right due >to lack of time to >be more precise. > > >I think that in general most of the working groups are >concerned about the >security aspects of their protocols. The problem as I see >it is not that >people don't care about security, or even that they are >unaware of the >security implications, the problems more often lie in >failing to asses >properly the level of risk and the effectiveness of the solutions. > >For example, Digest Authentication in HTTP was not >deployed until six years >after it was proposed and then only because of the IESG >fiat that protocols >could not use passwords in the clear as their only >security mechanism. The >group understood that sending passowrds in the clear was >not a good idea, >however the need to store the password in encrypted form >was considered to >be the overriding security priority. > >This type of behavior is also to be seen in 802.11b (and I >strongly suspect >Bluetooth). The group decides that the security issue is >'Wired Equivalent >Privacy' and all security proposals are going to be >measured against that >standard. The issues of integrity and access control are >essentially >foreclosed before the design begins. The fact that WEP >also botched the >crypto is actually irrelevant as the original security >spec is broken as >designed from the standpoint of enterprise deployment. > >Another set of pathologies come from groups who build a >risk model and then >insist upon a particular design even if it is >operationally infeasible. A >group will fixate on a particular aspect of a security >design even though it >has significant costs and provides no real security advantage. > >A prime example of this is protocols that use digital >signatures in place of >a MAC in order to provide for 'non-repudiation'. >Non-repudiation is fine and >usefull of course, but it is completely irrelevant if the >applications are >not expected to save the messages for later analysis or >pass them on to some >other party. > >What is going to be needed is a more systematic and >structured approach to >writing security considerations sections in RFCs. At the >moment those >sections are often no more than a list of potential >exploits. What I would >like to see appearing is an analysis that is akin to a >requirements analysis >but cast in security terms: > >What are the asserts that we are protecting? > What additional assets does our protocol architecture introduce? >What are the potential risks that those assets might be subject to? >What are the specific threats that are present in the described >architecture? >What controls are implemented to mitigate those risks/threats? >What is the level of residual risk? > > > Phill > > >Phillip Hallam-Baker FBCS C.Eng. >Principal Scientist >VeriSign Inc. >pbaker@verisign.com >781 245 6996 x227 > > -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPKIxzKJXuvVTI3urEQL5mACgwlkFtB4M0hC4LJ0gp7s1CvR+UiwAoJWE tnjrMY243XvdY9xaxwCBubBK =ObYe -----END PGP SIGNATURE----- From jis@MIT.EDU Wed Mar 27 16:07:56 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA13261; Wed, 27 Mar 2002 16:07:56 -0500 (EST) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA11675; Wed, 27 Mar 2002 16:07:56 -0500 (EST) Received: from jis.tzo.com (localhost [127.0.0.1]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA13255; Wed, 27 Mar 2002 16:07:55 -0500 (EST) Received: (from jis@localhost) by jis.tzo.com (8.8.7/8.8.7) id QAA01051; Wed, 27 Mar 2002 16:07:52 -0500 Date: Wed, 27 Mar 2002 16:07:52 -0500 From: "Jeffrey I. Schiller" To: RJ Atkinson Cc: Damir Rajnovic , saag@mit.edu Subject: Re: [saag] Security Advisor Council Proposal Message-ID: <20020327160752.A1038@mit.edu> References: <4.3.2.7.2.20020326080740.05b1b7e0@144.254.74.238> <0314028E-40CE-11D6-BA0C-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <0314028E-40CE-11D6-BA0C-00039357A82A@extremenetworks.com>; from rja@extremenetworks.com on Tue, Mar 26, 2002 at 10:27:41AM -0500 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 26, 2002 at 10:27:41AM -0500, RJ Atkinson wrote: > > On Tuesday, March 26, 2002, at 03:11 , Damir Rajnovic wrote: > > In addition to that I would like to see the intended modes of usage > > and an environment. > > In the IETF context, "environment" always is the Global Internet. yes and no. It *may* be the Global Internet. One of the issues we run into is where a technology that is used in a limited context is ported to IP (read: iSCSI). Indeed most Storage Area networks are not connected to the Internet, so the security environment is one that is somewhat protected. If we do storage networks over IP, there will still be a significant usage base that will be "protected." However the porting of a technology so that it works over IP, means that it is enabled for Global Internet Deployment... and there will certainly be some, likely significant use, of it in this context. Security Considerations *must* address this usage, even if the mechanisms may be disabled by end-users who do not need them. -Jeff --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 MessageID: nBCmvDFXu4dlvJ8FzvEsFfKUxP2aVDod iQA/AwUBPKI0qPAgc1f0FJUrEQLAgwCgijuV9s2bFJQ17E7mwe73MZQgBCwAn1lf SqSK+fYPWdA3+LzTJ1P/sdIN =Xp2x -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From gaus@cisco.com Thu Mar 28 02:44:06 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id CAA00415 for ; Thu, 28 Mar 2002 02:44:06 -0500 (EST) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA18990 for ; Thu, 28 Mar 2002 02:39:58 -0500 (EST) Received: from DRAJNOVI-W2K1.cisco.com (dhcp-rea-gp200-64-103-66-146.cisco.com [64.103.66.146]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA14956; Thu, 28 Mar 2002 08:39:45 +0100 (MET) Message-Id: <4.3.2.7.2.20020328073443.02c0f998@144.254.74.238> X-Sender: drajnovi@144.254.74.238 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Mar 2002 07:39:45 +0000 To: RJ Atkinson From: Damir Rajnovic Subject: Re: [saag] Security Advisor Council Proposal Cc: saag@mit.edu In-Reply-To: <0314028E-40CE-11D6-BA0C-00039357A82A@extremenetworks.com> References: <4.3.2.7.2.20020326080740.05b1b7e0@144.254.74.238> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 10:27 26/03/2002 -0500, RJ Atkinson wrote: >In the IETF context, "environment" always is the Global Internet. I know that. What I meant is what operating environment. Like, if my protocol is supposed to run via IPSec tunnel I can relax some requirements. However, if someone else decide to use it without IPSec then my protocol will fail. Or, my protocol is designed for A, B and C. If someone uses it for D my protocol will fail because it was not designed for that. In that case do not blame the protocol for failing. That is a kind of info I would like to see. Some standards and RFCs do have this but not all. Gaus ============== Damir Rajnovic , PSIRT Incident Manager, Cisco Systems Telephone: +44 7715 546 033 200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB ============== There is no insolvable problems. The question is can you accept the solution? From pete.chown@skygate.co.uk Thu Mar 28 05:11:24 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id FAA01622 for ; Thu, 28 Mar 2002 05:11:24 -0500 (EST) Received: from lion.skygate.co.uk (lion.skygate.co.uk [212.134.128.34]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id FAA26838 for ; Thu, 28 Mar 2002 05:11:22 -0500 (EST) Received: from hyena.skygate.co.uk ([10.0.0.2]) by lion.skygate.co.uk with esmtp (Exim 3.33 #1) id 16qWsK-0006El-00 for saag@mit.edu; Thu, 28 Mar 2002 10:11:20 +0000 Subject: Re: [saag] Security Advisor Council Proposal From: Pete Chown To: saag@mit.edu In-Reply-To: <4.3.2.7.2.20020328073443.02c0f998@144.254.74.238> References: <4.3.2.7.2.20020326080740.05b1b7e0@144.254.74.238> <4.3.2.7.2.20020328073443.02c0f998@144.254.74.238> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 28 Mar 2002 10:11:20 +0000 Message-Id: <1017310280.29922.21.camel@hyena.skygate.co.uk> Mime-Version: 1.0 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Damir Rajnovic wrote: > Like, > if my protocol is supposed to run via IPSec tunnel I can relax > some requirements. However, if someone else decide to use it > without IPSec then my protocol will fail. I think CORBA is a good example of this sort of problem. I suspect that originally it was meant to be used on isolated networks, and it was thought that this meant there were no security issues. So IIOP was defined with no built in security mechanism, and most standalone CORBA components like traders don't have control mechanisms of their own either. Adding security after the fact has been very difficult. The structure of IIOP means that it doesn't play very nicely with firewalls. This means that the CORBA firewall draft never seems to get completely finished. The other problem is that security in generic systems like CORBA is hard at the best of times. Because it is being added after the fact it becomes near impossible. Somehow you want to take a component like a trader that has no built in security mechanisms, and make it secure. This is a much harder task than writing secure components in the first place, and is one of the things that makes CORBAsec so complicated. I don't mean to blame the OMG; it's easy to be wise after the event. It is a good example, though, of why security must be designed into systems from the start. CORBA would be ideal for lots of Internet protocols, but the security and firewall issues hold it up. CORBAsec is so complicated that most ORBs don't support it. I also suspect that it is too complicated for a bug-free implementation. -- Pete From sommerfeld@orchard.arlington.ma.us Thu Mar 28 08:50:59 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA03086 for ; Thu, 28 Mar 2002 08:50:54 -0500 (EST) Received: from stack.hamachi.org (sommerfeld.ne.client2.attbi.com [66.31.126.43]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA08305 for ; Thu, 28 Mar 2002 08:50:54 -0500 (EST) Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 1E11B2711 for ; Thu, 28 Mar 2002 08:50:54 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 9104C2A4A; Thu, 28 Mar 2002 08:50:53 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 760EA1FDE for ; Thu, 28 Mar 2002 08:50:53 -0500 (EST) From: Bill Sommerfeld To: saag@mit.edu Reply-To: sommerfeld@orchard.arlington.ma.us Date: Thu, 28 Mar 2002 08:50:48 -0500 Message-Id: <20020328135053.9104C2A4A@orchard.arlington.ma.us> Subject: [saag] move IDENT (rfc1413) to HISTORIC? Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Prompted largely by Phil Nesser's comments at the plenary.. Is there any reason other than inertia why rfc1413 is still in "proposed standard" state? Seems like a good candidate for the scrap heap.. - Bill From pekkas@netcore.fi Thu Mar 28 09:02:22 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA03202 for ; Thu, 28 Mar 2002 09:02:22 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA00450 for ; Thu, 28 Mar 2002 09:02:21 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2SE2Fn22473; Thu, 28 Mar 2002 16:02:16 +0200 Date: Thu, 28 Mar 2002 16:02:15 +0200 (EET) From: Pekka Savola To: Bill Sommerfeld cc: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: <20020328135053.9104C2A4A@orchard.arlington.ma.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > Prompted largely by Phil Nesser's comments at the plenary.. > > Is there any reason other than inertia why rfc1413 is still in > "proposed standard" state? Seems like a good candidate for the scrap > heap.. Well, it _is_ actually being used (though questionably).. a huge difference to N^2 other drafts no one has even heard of before :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From sommerfeld@orchard.arlington.ma.us Thu Mar 28 09:43:00 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id JAA03652 for ; Thu, 28 Mar 2002 09:43:00 -0500 (EST) Received: from stack.hamachi.org (sommerfeld.ne.client2.attbi.com [66.31.126.43]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA13040 for ; Thu, 28 Mar 2002 09:42:59 -0500 (EST) Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id E7A89270F; Thu, 28 Mar 2002 09:42:58 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id BC22A2A4A; Thu, 28 Mar 2002 09:42:58 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id A41191FDE; Thu, 28 Mar 2002 09:42:58 -0500 (EST) From: Bill Sommerfeld To: Pekka Savola Cc: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: Message from Pekka Savola of "Thu, 28 Mar 2002 16:02:15 +0200." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Thu, 28 Mar 2002 09:42:53 -0500 Message-Id: <20020328144258.BC22A2A4A@orchard.arlington.ma.us> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > Well, it _is_ actually being used (though questionably).. a huge > difference to N^2 other drafts no one has even heard of before :-) The definition of "historic" status in 2026: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. This says nothing about whether a protocol is actually being used, but rather whether the protocol is still a good idea.. - Bill From randy@psg.com Thu Mar 28 12:11:40 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA05629 for ; Thu, 28 Mar 2002 12:11:40 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA08833 for ; Thu, 28 Mar 2002 12:11:39 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16qdQ3-0003uY-00; Thu, 28 Mar 2002 09:10:35 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pete Chown Cc: saag@mit.edu Subject: Re: [saag] Security Advisor Council Proposal References: <4.3.2.7.2.20020326080740.05b1b7e0@144.254.74.238> <4.3.2.7.2.20020328073443.02c0f998@144.254.74.238> <1017310280.29922.21.camel@hyena.skygate.co.uk> Message-Id: Date: Thu, 28 Mar 2002 09:10:35 -0800 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > I think CORBA is a good example of this sort of problem. and way back at the begining of corba, it was impossible to get anyone to take WAN transport security as a serious issue. "we have all been here before" -- csny From mouse@Sparkle.Rodents.Montreal.QC.CA Thu Mar 28 13:21:08 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA06568 for ; Thu, 28 Mar 2002 13:21:08 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA03622 for ; Thu, 28 Mar 2002 13:21:06 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA26734; Thu, 28 Mar 2002 13:21:04 -0500 (EST) Date: Thu, 28 Mar 2002 13:21:04 -0500 (EST) From: der Mouse Message-Id: <200203281821.NAA26734@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: <20020328135053.9104C2A4A@orchard.arlington.ma.us> References: <20020328135053.9104C2A4A@orchard.arlington.ma.us> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > Is there any reason other than inertia why rfc1413 is still in > "proposed standard" state? Seems like a good candidate for the scrap > heap.. [...another message...] > The definition of "historic" status in 2026: [...] > This says nothing about whether a protocol is actually being used, > but rather whether the protocol is still a good idea.. As I remarked on another list when the subject came up, speaking as a sysadmin, _I_ certainly wouldn't be caught dead without it. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From narten@us.ibm.com Thu Mar 28 14:17:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA07175 for ; Thu, 28 Mar 2002 14:17:35 -0500 (EST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA22770 for ; Thu, 28 Mar 2002 14:17:34 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g2SJGID03847; Thu, 28 Mar 2002 14:16:18 -0500 Message-Id: <200203281916.g2SJGID03847@cichlid.adsl.duke.edu> To: sommerfeld@orchard.arlington.ma.us cc: Pekka Savola , saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: Message from Bill Sommerfeld of "Thu, 28 Mar 2002 09:42:53 EST." <20020328144258.BC22A2A4A@orchard.arlington.ma.us> Date: Thu, 28 Mar 2002 14:16:18 -0500 From: Thomas Narten Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > The definition of "historic" status in 2026: > A specification that has been superseded by a more recent > specification or is for any other reason considered to be obsolete is > assigned to the "Historic" level. > This says nothing about whether a protocol is actually being used, but > rather whether the protocol is still a good idea.. Some background. The IESG doesn't like to reclassify stuff as historic just because it is old. In particular, if it is still being used, and there is little likelihood that folks will stop using it in the near future, we have tended to not want to reclassify as historic. On the other hand, if something is really considered to be a Bad Thing, and there are better alternatives that people should be using instead, we have reclassified something as historic as part of an attempt to move people to something clearly better. One example is moving from RIPv1 to RIPv2 (which supports variable subnets). Thomas From HUITEMA@windows.microsoft.com Thu Mar 28 14:20:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA07228 for ; Thu, 28 Mar 2002 14:20:18 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA23926 for ; Thu, 28 Mar 2002 14:20:18 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Mar 2002 11:20:17 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Mar 2002 11:20:17 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Mar 2002 11:20:16 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Mar 2002 11:20:16 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 28 Mar 2002 11:16:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [saag] move IDENT (rfc1413) to HISTORIC? Date: Thu, 28 Mar 2002 11:16:49 -0800 Message-ID: Thread-Topic: [saag] move IDENT (rfc1413) to HISTORIC? thread-index: AcHWhyqMV+72ynK6TzK3tCepaEq7zAABiXYQ From: "Christian Huitema" To: "der Mouse" , X-OriginalArrivalTime: 28 Mar 2002 19:16:51.0536 (UTC) FILETIME=[1D6ADD00:01C1D68D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id OAA07228 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > > Is there any reason other than inertia why rfc1413 is still in > > "proposed standard" state? Seems like a good candidate for the scrap > > heap.. > [...another message...] > > The definition of "historic" status in 2026: [...] > > This says nothing about whether a protocol is actually being used, > > but rather whether the protocol is still a good idea.. > > As I remarked on another list when the subject came up, speaking as a > sysadmin, _I_ certainly wouldn't be caught dead without it. I personally believe IDENT is at best useless and in many cases dangerous. Moving to historic is definitely the right thing. -- Christian Huitema From mouse@Sparkle.Rodents.Montreal.QC.CA Thu Mar 28 17:01:13 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id RAA08630 for ; Thu, 28 Mar 2002 17:01:13 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA08909 for ; Thu, 28 Mar 2002 17:01:12 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA27584; Thu, 28 Mar 2002 17:01:10 -0500 (EST) Date: Thu, 28 Mar 2002 17:01:10 -0500 (EST) From: der Mouse Message-Id: <200203282201.RAA27584@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: References: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >>> [...RFC1413...] >> As I remarked on another list when the subject came up, speaking as >> a sysadmin, _I_ certainly wouldn't be caught dead without it. > I personally believe IDENT is at best useless and in many cases > dangerous. Moving to historic is definitely the right thing. The one does not follow from the other. I personally believe ident has value, though it requires care to use correctly. To state opinion as fact the way you did, moving it to historic is definitely Wrong. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From apb@cequrux.com Thu Mar 28 10:59:20 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA04619 for ; Thu, 28 Mar 2002 10:59:19 -0500 (EST) Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA21146 for ; Thu, 28 Mar 2002 10:59:17 -0500 (EST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id RAA03340 for ; Thu, 28 Mar 2002 17:59:11 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 3338; Thu Mar 28 17:58:35 2002 Date: Thu, 28 Mar 2002 17:58:30 +0200 From: Alan Barrett To: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? Message-ID: <20020328155829.GF20086@apb.cequrux.com> References: <20020328135053.9104C2A4A@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020328135053.9104C2A4A@orchard.arlington.ma.us> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > Prompted largely by Phil Nesser's comments at the plenary.. > > Is there any reason other than inertia why rfc1413 is still in > "proposed standard" state? Seems like a good candidate for the scrap > heap.. ident answers the question "what information does the sysadmin feel like providing about this connection", not anything like "what is the real user name". As long as you don't expect more than that, and understand that you sometimes get less than that (e.g.in the case of spoofed connections with or without replay attacks), I believe that it can be useful. Most people who say that ident is useless (and many people who say that ident is useful) seem to have the wrong idea about what ident is useful for. It's useful for a sort of outsourced logging of a subset of your TCP connections. If I have a multiuser host and you have a publicly accessible server, and one of my users accesses your server, then the identd service on my multi-user host is *not* there to tell you the username of one of my users; you should treat it as an opaque cookie, and simply log it if you think that a future investigation might be appropriate. Ideally, it will be an encrypted cookie that's resistant to reply attacks. If an investigation into suspicious activity is later undertaken, the ident information that you logged will help me find which of my users was involved, without my having had to log the user names for all the outbound connections that did not trigger ident lookups. --apb (Alan Barrett) From rmeijer@xs4all.nl Thu Mar 28 18:49:50 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id SAA01168 for ; Thu, 28 Mar 2002 18:49:50 -0500 (EST) Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA10793 for ; Thu, 28 Mar 2002 18:49:50 -0500 (EST) Received: from xs3.xs4all.nl (rmeijer@xs3.xs4all.nl [194.109.6.44]) by mxzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2SNnnn8035162; Fri, 29 Mar 2002 00:49:49 +0100 (CET) Received: from localhost (rmeijer@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA24278; Fri, 29 Mar 2002 00:49:49 +0100 (CET) Date: Fri, 29 Mar 2002 00:49:48 +0100 (CET) From: Rob J Meijer To: Christian Huitema cc: der Mouse , saag@mit.edu Subject: RE: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Thu, 28 Mar 2002, Christian Huitema wrote: > > As I remarked on another list when the subject came up, speaking as a > > sysadmin, _I_ certainly wouldn't be caught dead without it. > > I personally believe IDENT is at best useless and in many cases > dangerous. Moving to historic is definitely the right thing. > In order for a widely used protocol that aparently many people find provides usefull functionality to become historic, wouldn't there at least need to be a viable (more suitable) protocol with a proposed-standard status that will provide for this same functionality and has a wide consensus to be the more suitable protocol of the two ? Rob J Meijer From sommerfeld@orchard.arlington.ma.us Thu Mar 28 19:01:22 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA01283 for ; Thu, 28 Mar 2002 19:01:16 -0500 (EST) Received: from stack.hamachi.org (sommerfeld.ne.client2.attbi.com [66.31.126.43]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA13107 for ; Thu, 28 Mar 2002 19:01:16 -0500 (EST) Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 526EF270C; Thu, 28 Mar 2002 19:01:16 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 29CA72A4A; Thu, 28 Mar 2002 19:01:16 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 1AABD1FDE; Thu, 28 Mar 2002 19:01:16 -0500 (EST) From: Bill Sommerfeld To: Alan Barrett Cc: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: Message from Alan Barrett of "Thu, 28 Mar 2002 17:58:30 +0200." <20020328155829.GF20086@apb.cequrux.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Thu, 28 Mar 2002 19:01:10 -0500 Message-Id: <20020329000116.29CA72A4A@orchard.arlington.ma.us> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > It's useful for a sort of outsourced logging of a subset of your > TCP connections. It's not even very good for that -- since the ident protocol is itself not secured, man-in-the-middle attacks on it are trivial, even in the presence of "opaque" identifiers -- an attacker doing a man-in-the-middle attack on the IDENT protocol could forge TCP resets and cause the IDENT client to conclude that the system was not running an IDENT server, and substitute a different port pair in the request (and likewise substitute the ports in the reply). Also, a MitM attacker bearing a vague resemblance to a NAT could also substitute a different remote IP address. If you need this sort of auditing, there's really no substitute for logging all outbound connections. - Bill From steve@stevecrocker.com Thu Mar 28 19:06:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA01315 for ; Thu, 28 Mar 2002 19:06:18 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA26641 for ; Thu, 28 Mar 2002 19:06:15 -0500 (EST) Received: from [66.92.150.17] (HELO SDC3) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with SMTP id 2878267 for saag@mit.edu; Thu, 28 Mar 2002 19:06:14 -0500 From: "Steve Crocker" To: Subject: RE: [saag] move IDENT (rfc1413) to HISTORIC? Date: Thu, 28 Mar 2002 19:06:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020328155829.GF20086@apb.cequrux.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Wow! I had lost track of ident and assumed it had made it through the hurdles to full maturity. This was started on my watch as security area director and entailed considerable controversy on two points. The first controversial issue was whether it added any real security and, as a collateral matter, whether it would tend to mislead people into thinking it provided more security than it does. The second area of controversy revolved around the operation of the working group. Let me speak mostly about the first and only summarily about the second. We considered the first question fairly carefully. Some argued ident isn't very secure. After listening closely to that argument, we decided it was nonetheless useful. The Internet has flourished with a generally open approach to adding new mechanisms, and we chose not to censor this effort despite a clear understanding that it's not an adequate way to convey identity in an authoritative way. Alan Barrett's note below is a good description of the utility, and I still think it was appropriate to have the effort go forward. That said, I'm surprised it didn't move past the Proposed stage. The second area of contention was in the operation and dialog within the working group after we approved the charter, but we reorganized the group and the effort moved forward. Getting to the Proposed state represented a significant milestone, and, as I said at the beginning of the note, I would have guessed it would proceed up the ladder after that. If the protocol is genuinely not being used, then indeed it's time to retire it to HISTORIC. But if multiple implementations exist and it's still being used, then it belongs in the current portfolio. I apologize if I'm missing some key pieces of context or history. I wasn't at the plenary. Steve > -----Original Message----- > From: saag-admin@mit.edu [mailto:saag-admin@mit.edu]On Behalf Of Alan > Barrett > Sent: Thursday, March 28, 2002 10:59 AM > To: saag@mit.edu > Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? > > > On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > > Prompted largely by Phil Nesser's comments at the plenary.. > > > > Is there any reason other than inertia why rfc1413 is still in > > "proposed standard" state? Seems like a good candidate for the scrap > > heap.. > > ident answers the question "what information does the sysadmin feel like > providing about this connection", not anything like "what is the real > user name". As long as you don't expect more than that, and understand > that you sometimes get less than that (e.g.in the case of spoofed > connections with or without replay attacks), I believe that it can be > useful. > > Most people who say that ident is useless (and many people who say that > ident is useful) seem to have the wrong idea about what ident is useful > for. It's useful for a sort of outsourced logging of a subset of your > TCP connections. > > If I have a multiuser host and you have a publicly accessible server, > and one of my users accesses your server, then the identd service on my > multi-user host is *not* there to tell you the username of one of my > users; you should treat it as an opaque cookie, and simply log it if > you think that a future investigation might be appropriate. Ideally, > it will be an encrypted cookie that's resistant to reply attacks. If > an investigation into suspicious activity is later undertaken, the > ident information that you logged will help me find which of my users > was involved, without my having had to log the user names for all the > outbound connections that did not trigger ident lookups. > > --apb (Alan Barrett) > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag From sommerfeld@orchard.arlington.ma.us Thu Mar 28 19:06:50 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA01320 for ; Thu, 28 Mar 2002 19:06:50 -0500 (EST) Received: from stack.hamachi.org (sommerfeld.ne.client2.attbi.com [66.31.126.43]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA26781 for ; Thu, 28 Mar 2002 19:06:49 -0500 (EST) Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 729EE270F; Thu, 28 Mar 2002 19:06:49 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 4DFBE2A4A; Thu, 28 Mar 2002 19:06:49 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 420E91FDE; Thu, 28 Mar 2002 19:06:49 -0500 (EST) From: Bill Sommerfeld To: Rob J Meijer Cc: Christian Huitema , der Mouse , saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: Message from Rob J Meijer of "Fri, 29 Mar 2002 00:49:48 +0100." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Thu, 28 Mar 2002 19:06:44 -0500 Message-Id: <20020329000649.4DFBE2A4A@orchard.arlington.ma.us> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > In order for a widely used protocol that aparently many people find > provides usefull functionality to become historic, wouldn't there > at least need to be a viable (more suitable) protocol with a > proposed-standard status that will provide for this same functionality and > has a wide consensus to be the more suitable protocol of the two ? So, here are just a few of them: 1510 The Kerberos Network Authentication Service (V5). J. Kohl, C. Neuman. September 1993. (Format: TXT=275395 bytes) (Status: PROPOSED STANDARD) 2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. (Format: TXT=170401 bytes) (Status: PROPOSED STANDARD) 2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman. January 1999. (Format: TXT=15120 bytes) (Obsoleted by RFC3207) (Status: PROPOSED STANDARD) 2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. (Format: TXT=32440 bytes) (Status: PROPOSED STANDARD) 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security. P. Hoffman. February 2002. (Format: TXT=18679 bytes) (Obsoletes RFC2487) (Status: PROPOSED STANDARD) .... From HUITEMA@windows.microsoft.com Thu Mar 28 19:40:44 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA01738 for ; Thu, 28 Mar 2002 19:40:43 -0500 (EST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA21310 for ; Thu, 28 Mar 2002 19:40:43 -0500 (EST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Mar 2002 16:40:42 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Mar 2002 16:40:42 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Mar 2002 16:40:41 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Mar 2002 16:40:41 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Thu, 28 Mar 2002 16:37:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [saag] move IDENT (rfc1413) to HISTORIC? Date: Thu, 28 Mar 2002 16:37:24 -0800 Message-ID: Thread-Topic: [saag] move IDENT (rfc1413) to HISTORIC? thread-index: AcHWshgDFFpOzAywQ8uvxwC5YCBlsgABvX5w From: "Christian Huitema" To: "Alan Barrett" , X-OriginalArrivalTime: 29 Mar 2002 00:37:25.0595 (UTC) FILETIME=[E5CF5AB0:01C1D6B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id TAA01738 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > If I have a multiuser host and you have a publicly accessible server, > and one of my users accesses your server, then the identd service on my > multi-user host is *not* there to tell you the username of one of my > users; you should treat it as an opaque cookie, and simply log it if > you think that a future investigation might be appropriate. Ideally, > it will be an encrypted cookie that's resistant to reply attacks. If > an investigation into suspicious activity is later undertaken, the > ident information that you logged will help me find which of my users > was involved, without my having had to log the user names for all the > outbound connections that did not trigger ident lookups. We could discuss whether even that is useful -- I have some strong doubts. But there is definitely no suggestion of this behavior in the text of RFC 1413. The example in RFC 1413 is "6193, 23 : USERID : UNIX : stjohns", which is definitely not "an opaque cookie." Moreover, the security consideration mentions: If you wouldn't run a "finger" server due to privacy considerations you may not want to run this protocol. When I mentioned "potentially dangerous", I considered usage such as "IDENT scanning", as documented in Hacking Exposed: send an ident request for a service port, and many systems (mostly Unix) will respond with the owner of the process that is bound to that particular port. -- Christian Huitema From randy@psg.com Thu Mar 28 19:41:32 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA01747 for ; Thu, 28 Mar 2002 19:41:32 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA03919 for ; Thu, 28 Mar 2002 19:41:31 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16qkSQ-000H4o-00; Thu, 28 Mar 2002 16:41:30 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Christian Huitema" Cc: saag@mit.edu Subject: RE: [saag] move IDENT (rfc1413) to HISTORIC? References: Message-Id: Date: Thu, 28 Mar 2002 16:41:30 -0800 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > I personally believe IDENT is at best useless and in many cases > dangerous. this discussion happens every six months. which ie better, vi or emacs? randy From ho@alum.mit.edu Thu Mar 28 20:05:37 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA01992 for ; Thu, 28 Mar 2002 20:05:36 -0500 (EST) Received: from mgr2.xmission.com (mgr2.xmission.com [198.60.22.202]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA25903 for ; Thu, 28 Mar 2002 20:05:36 -0500 (EST) Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr2.xmission.com with esmtp (Exim 3.22 #1) id 16qkpk-0003ao-00 for saag@mit.edu; Thu, 28 Mar 2002 18:05:36 -0700 Received: from [166.70.8.43] (helo=alum.mit.edu) by mail.xmission.com with esmtp (Exim 3.22 #1) id 16qkpj-0007xS-00 for saag@mit.edu; Thu, 28 Mar 2002 18:05:35 -0700 Message-ID: <3CA3BD92.5050307@alum.mit.edu> Date: Thu, 28 Mar 2002 18:04:18 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? References: <20020329000649.4DFBE2A4A@orchard.arlington.ma.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: The question would seem to be not if anyone is using it, but if anyone is using the information it provides. Are people getting reports of problems, using the IDENT info to look up the user, and thus stop some kind of computer abuse? Or have firewalls and filtering proven more effective? Being as the mechanism seemed designed to enable cooperating admins to slap the hands of simple-minded bad users (or more likely, users - simple-minded or not - whose accounts were somehow compromised), and that we know that number of clueless users, good and bad, never decreases, I can imagine that IDENT might have continuing value, but it also seems to involve manual, time-consuming followup that most admins wouldn't have time for. Hilarie Emacs is better, especially if you also play a stringed instrument. From shalunov@internet2.edu Thu Mar 28 20:34:41 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA02271 for ; Thu, 28 Mar 2002 20:34:41 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA01277 for ; Thu, 28 Mar 2002 20:34:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 26B575ED3A for ; Thu, 28 Mar 2002 20:34:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 473305EBCD for ; Thu, 28 Mar 2002 20:34:40 -0500 (EST) To: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? References: <20020329000649.4DFBE2A4A@orchard.arlington.ma.us> <3CA3BD92.5050307@alum.mit.edu> From: stanislav shalunov Date: 28 Mar 2002 20:34:39 -0500 In-Reply-To: <3CA3BD92.5050307@alum.mit.edu> Message-ID: <874rj0xikw.fsf@cain.internet2.edu> Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "The Purple Streak (Hilarie Orman)" writes: > Are people getting reports of problems, using the IDENT info to look > up the user, and thus stop some kind of computer abuse? In my (now rather remote) days as a sysadmin who had to run machines with hundreds of student accounts, I found IDENT tokens sent to me by remote parties (such as IRC server operators) an invaluable tool to help identify accounts with stolen passwords. Machines with hundreds and thousands of shell accounts still exist. Kids still like to IRC from stolen accounts. I don't see why IDENT has become any less useful than it was before. People who talk about IDENT being useless obviously have in mind machines with small number of users or machines with weak localhost security. IDENT isn't ideal. But useless? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Letters in this message are closer than they appear. From pbaker@verisign.com Fri Mar 29 11:53:39 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA10575 for ; Fri, 29 Mar 2002 11:53:39 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18540 for ; Fri, 29 Mar 2002 11:53:39 -0500 (EST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g2TGmXO23624; Fri, 29 Mar 2002 08:48:33 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 08:53:31 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A3C@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'jns@digitalisland.net'" , "Hallam-Baker, Phillip" , saag@mit.edu Subject: RE: [saag] Security Advisor Council Proposal Date: Fri, 29 Mar 2002 08:53:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: My point is that an established system with acceptable security is often governed by controls that are implicit. When the system is transfered to a different environment those implicit controls are forgotten. The anaology method does not make for good security practice. For example. 1) A 4 digit PIN is secure in the ATM world because the account number is embedded in a card and must be presented to a trusted terminal, furthermore this is a manual process which reduces the rate at which a dictionary attack may be performed and requires the perpetrator to risk apprehension by law enforcement. The same 4 digit PIN and account mechanism is completely insecure on the Internet. Although the probability of breaking a given account before it is locked out is still 10,000/3 = 1 in 3,333, the restriction on the number of accounts attacked is removed. I have closed my account with one online broker whose security consists today of a 4 digit PIN and and account number that consists of the brokers routing number, a sequence number and a checksum. The situation is even worse when one considers that an ATM machine is typically limited to transactions of up to $200 or $500. The average funds in a brokerage account is probably $20,000 to $100,000 and amounts in the millions are not uncommon (albeit less so since Clinton left office and the gap between rich and poor has been narrowed). 2) Wireless Equivalent Privacy. The control that was overlooked is that physical access to a network cable is actually a significant if not insuperable barrier. It is true that an attacker can often access ethernet cable runs through public spaces of a building (particularly if a company occupies non-contiguous areas of a building), however in practice this type of attack puts the attacker at considerable personal risk. Phill > -----Original Message----- > From: John N. Stewart [mailto:jns@digitalisland.net] > Sent: Wednesday, March 27, 2002 3:56 PM > To: 'Hallam-Baker, Phillip'; saag@mit.edu > Subject: RE: [saag] Security Advisor Council Proposal > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Phill: > > I'd like to play back to what I took out of this, to see if I read > it correctly, and then ponder an idea related to how we approached > developing products over the years. > > If I read your proposal correctly, the weakness is that by leveraging > previously bad works, ignorance (the good definition), or just a > clean miss in understanding the issues, there are areas of both > proposal and development that address security incorrectly. With > that in mind, if it is doesn't surface to the right audience, > security will be accepted or implemented incorrectly in standards > bodies. If nothing else, that is wasteful. > > - -- > > In an effort to address this, some methodology whereby security > aspects of new or modified areas are scrutinized by good people, in > the hopes of lowering this wasteful set of efforts as well as ideally > bolster the security aspects for a given protocol or specification. > In that vein, either through callouts in the design spec or a review > forum of sorts - the requirements and the answers are put to the > test. > > In our product development lifecycle, and in other ones and previous > ones I've used, an approach is to have a callout section in the spec > that asks and answers those questions. It makes reviewing just those > aspects simpler. > > I hope this re-engages the dialogue. > > - --j > > > > > This message and any files or text attached to it are intended only > for the recipients named above, and contain information that may be > confidential or privileged. If you are not an intended recipient, you > must not read, copy, use or disclose this communication. Please also > notify the sender by replying to this me. > > >-----Original Message----- > >From: saag-admin@mit.edu [mailto:saag-admin@mit.edu]On Behalf Of > >Hallam-Baker, Phillip > >Sent: Monday, March 25, 2002 10:15 AM > >To: saag@mit.edu > >Subject: [saag] Security Advisor Council Proposal > > > > > >Just thought it might be appropriate to put into words > >what I tried to say > >at the IETF SAAG but might not have come across right due > >to lack of time to > >be more precise. > > > > > >I think that in general most of the working groups are > >concerned about the > >security aspects of their protocols. The problem as I see > >it is not that > >people don't care about security, or even that they are > >unaware of the > >security implications, the problems more often lie in > >failing to asses > >properly the level of risk and the effectiveness of the > solutions. > > > >For example, Digest Authentication in HTTP was not > >deployed until six years > >after it was proposed and then only because of the IESG > >fiat that protocols > >could not use passwords in the clear as their only > >security mechanism. The > >group understood that sending passowrds in the clear was > >not a good idea, > >however the need to store the password in encrypted form > >was considered to > >be the overriding security priority. > > > >This type of behavior is also to be seen in 802.11b (and I > >strongly suspect > >Bluetooth). The group decides that the security issue is > >'Wired Equivalent > >Privacy' and all security proposals are going to be > >measured against that > >standard. The issues of integrity and access control are > >essentially > >foreclosed before the design begins. The fact that WEP > >also botched the > >crypto is actually irrelevant as the original security > >spec is broken as > >designed from the standpoint of enterprise deployment. > > > >Another set of pathologies come from groups who build a > >risk model and then > >insist upon a particular design even if it is > >operationally infeasible. A > >group will fixate on a particular aspect of a security > >design even though it > >has significant costs and provides no real security advantage. > > > >A prime example of this is protocols that use digital > >signatures in place of > >a MAC in order to provide for 'non-repudiation'. > >Non-repudiation is fine and > >usefull of course, but it is completely irrelevant if the > >applications are > >not expected to save the messages for later analysis or > >pass them on to some > >other party. > > > >What is going to be needed is a more systematic and > >structured approach to > >writing security considerations sections in RFCs. At the > >moment those > >sections are often no more than a list of potential > >exploits. What I would > >like to see appearing is an analysis that is akin to a > >requirements analysis > >but cast in security terms: > > > >What are the asserts that we are protecting? > > What additional assets does our protocol architecture > introduce? > >What are the potential risks that those assets might be subject > to? > >What are the specific threats that are present in the described > >architecture? > >What controls are implemented to mitigate those risks/threats? > >What is the level of residual risk? > > > > > > Phill > > > > > >Phillip Hallam-Baker FBCS C.Eng. > >Principal Scientist > >VeriSign Inc. > >pbaker@verisign.com > >781 245 6996 x227 > > > > > > -----BEGIN PGP SIGNATURE----- > Version: PGP 7.1.1 > > iQA/AwUBPKIxzKJXuvVTI3urEQL5mACgwlkFtB4M0hC4LJ0gp7s1CvR+UiwAoJWE > tnjrMY243XvdY9xaxwCBubBK > =ObYe > -----END PGP SIGNATURE----- > From phil@nesser.com Sun Mar 31 02:30:56 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id CAA09302 for ; Sun, 31 Mar 2002 02:30:55 -0500 (EST) Received: from host238.2alpha.com ([192.104.59.100]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA27562 for ; Sun, 31 Mar 2002 02:30:54 -0500 (EST) Received: from A30P ([192.104.59.110]) by host238.2alpha.com (8.11.3/8.11.0) with ESMTP id g2V7OPa28104; Sat, 30 Mar 2002 23:24:25 -0800 (PST) Reply-To: From: "Philip J. Nesser II" To: , Subject: RE: [saag] move IDENT (rfc1413) to HISTORIC? Date: Sat, 30 Mar 2002 23:30:41 -0800 Organization: Nesser & Nesser Consulting Message-ID: <037a01c1d885$fcd60920$b73b68c0@A30P> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20020328135053.9104C2A4A@orchard.arlington.ma.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I have been busy with some other projects the last few days, so I am sorry that I haven't participated in this discussion sooner. I will attempt to address a number of points in a single message, rather than sending out numerous replies. The IETF faces a big problem with its standards track documents. The issue has come up here in regards to IDENT, but the same discussion could surface in dozens of other WGs if it got pushed. As can be seen from Steve Crocker's message, protocols get approved to the PS state and then they linger forever. Why aren't they advanced? Often it is because there are no champions. WG gets formed, a protocol is developed, an RFC is published to the PS state, the WG disbands. What happens next? Sometimes the protocol sits around and dies. Does is ever move from PS to Historic? No. Sometimes a protocol grows slowly and get two interoperable implementations. Does it go to DS? Rarely (less than 10% of the time)? Sometimes it is widely deployed across the Internet (i.e. NNTP or even IDENT). What happens? Usually nothing. I hate to say this, but the *process* has problems. I don't want to see the IESG overloaded with dozens of requests to reclassify older RFCs to different status, but we need to clean this mess up. I also think that the Historic classification is too widely interpreted in too many different ways for it to be the catch all (i.e. "hey lets just make them all historic"). Right now there is a big flame fest going on in the poised area regarding the Nomcomm issues that Brian Carpenter brought up. When they die down a little and people can focus on a different issue, I plan to bring the topics that I mentioned at the Plenary to the IETF mailing list with a redirection to the POISED list. I would suggest that SAAG hold off on making any move on IDENT or any other security RFC until that discussion has a bit of time. I dearly want to see this issue resolved in a reasonable way, but I want to see it done as a concerted effort with a clear direction. Otherwise, it might add to the total work that needs to be done. ---> Phil -----Original Message----- From: saag-admin@mit.edu [mailto:saag-admin@mit.edu] On Behalf Of Bill Sommerfeld Sent: Thursday, March 28, 2002 5:51 AM To: saag@mit.edu Subject: [saag] move IDENT (rfc1413) to HISTORIC? Prompted largely by Phil Nesser's comments at the plenary.. Is there any reason other than inertia why rfc1413 is still in "proposed standard" state? Seems like a good candidate for the scrap heap.. - Bill _______________________________________________ saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag From rja@extremenetworks.com Sun Mar 31 10:34:03 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id KAA12525 for ; Sun, 31 Mar 2002 10:34:03 -0500 (EST) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA29177 for ; Sun, 31 Mar 2002 10:34:02 -0500 (EST) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id D6AD167103; Sun, 31 Mar 2002 10:58:24 -0500 (EST) Date: Sun, 31 Mar 2002 10:33:57 -0500 Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: To: From: RJ Atkinson In-Reply-To: <037a01c1d885$fcd60920$b73b68c0@A30P> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Sunday, March 31, 2002, at 02:30 , Philip J. Nesser II wrote: > I hate to say this, but the *process* has problems. I don't want > to see the IESG overloaded with dozens of requests to reclassify > older RFCs to different status, but we need to clean this mess up. > I also think that the Historic classification is too widely > interpreted in too many different ways for it to be the catch all > (i.e. "hey lets just make them all historic"). The problem lies largely within the IESG, according to several different IESG members. Externally, I can say that several attempts to move OTP WG documents from Draft Standard to Full Standard were educational, if not successful. IMHO, we need a simpler process. I'd propose renaming "Draft Standard" as "Standard" (keeping the same requirements as for Draft Standard) and moving to a 2-level standards track. I'd also advocate re-tilting the balance for advancement from PS to FS so that there it is harder for a single IESG person to push back on advancement of something that already went out as PS. (And followups to these ideas belong on the ietf-process list, not SAAG list). In practice, the deployed Internet runs largely on Internet-Drafts (e.g. draft-martini-* MPLS VPNs) and Proposed Standard RFCs. Technology that is (perceived as) useful gets deployed REGARDLESS of whether it is in an RFC or is on the standards-track. It is time for the IETF to extract its head from the sand about this reality and become more nimble. Ran rja@extremenetworks.com From moore@cs.utk.edu Sun Mar 31 13:49:17 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id NAA14373 for ; Sun, 31 Mar 2002 13:49:16 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA21164 for ; Sun, 31 Mar 2002 13:49:16 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2VInAZ24550; Sun, 31 Mar 2002 13:49:10 -0500 (EST) Message-Id: <200203311849.g2VInAZ24550@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson cc: phil@nesser.com, saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-reply-to: (Your message of "Sun, 31 Mar 2002 10:33:57 EST.") Date: Sun, 31 Mar 2002 13:49:10 -0500 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > The problem lies largely within the IESG, according to several > different IESG members. it might be the case for one or two particular documents, or maybe even in one particular area. but I don't think the general problem is with IESG. most people are far more interested in getting agreement on the definition of a new protocol than they are in cleaning up old specifications, doing feature-by-feature interoperability tests and documenting the results, or finding out whether an old PS protocol is still applicable for anything. when I was on IESG, most of the protocols I saw get advanced to DS were protocols whose PS definitions had enough problems that there was some incentive to fix them. Keith From ketil@froyn.net Thu Mar 28 20:25:37 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id UAA02154 for ; Thu, 28 Mar 2002 20:25:37 -0500 (EST) Received: from lexx.infeline.org ([213.225.90.118]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id UAA11192 for ; Thu, 28 Mar 2002 20:25:36 -0500 (EST) Received: (qmail 24521 invoked by uid 99); 29 Mar 2002 01:26:41 -0000 Received: from unknown (HELO lexx.infeline.org) (ketil@213.225.90.118) by lexx.infeline.org with SMTP; 29 Mar 2002 01:26:41 -0000 Date: Fri, 29 Mar 2002 02:26:41 +0100 (CET) From: Ketil Froyn X-X-Sender: ketil@lexx.infeline.org To: "saag@mit.edu" Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: <3CA3BD92.5050307@alum.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: It is quite interesting that the latest program on freshmeat.net right now was "slidentd", with this description: "slidentd is a minimal ident (RFC1413) daemon which runs from inetd, xinetd, or tcpserver. It is similar in purpose to pidentd, which is installed with most Linux systems. However its design goals are somewhat different. It was written because the author wanted a very small, simple daemon that would not give out any sensitive information (such as usernames). In this regard it is not RFC compliant (RFC 1413 requires the daemon to be insecure by default with secure settings as an option)." Searching for ident on freshmeat, you will also find "nullidentd" and "fakeidentd", with similar functionality. I actually think one of the main uses of ident is that some (all?) irc servers require it, and therefore people need something to answer that port to chat with their friends. Just my 2 øre :) Ketil From apb@cequrux.com Fri Mar 29 05:18:01 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id FAA07259 for ; Fri, 29 Mar 2002 05:18:01 -0500 (EST) Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id FAA18181 for ; Fri, 29 Mar 2002 05:18:00 -0500 (EST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id MAA04395 for ; Fri, 29 Mar 2002 12:17:58 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 4388; Fri Mar 29 12:17:55 2002 Date: Fri, 29 Mar 2002 12:17:53 +0200 From: Alan Barrett To: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? Message-ID: <20020329101753.GI20086@apb.cequrux.com> References: <20020328155829.GF20086@apb.cequrux.com> <20020329000116.29CA72A4A@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020329000116.29CA72A4A@orchard.arlington.ma.us> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > > It's useful for a sort of outsourced logging of a subset of your > > TCP connections. > > It's not even very good for that -- since the ident protocol is itself > not secured, man-in-the-middle attacks on it are trivial, even in the > presence of "opaque" identifiers Sure, but some people's threat model is such that ident is still useful to them. > If you need this sort of auditing, there's really no substitute for > logging all outbound connections. It would be nice if some widely used operating systems had an easy way to log user names/process-ids for a configurable subset of outgoing commentions. --apb (Alan Barrett) From apb@cequrux.com Fri Mar 29 08:27:34 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id IAA08664 for ; Fri, 29 Mar 2002 08:27:34 -0500 (EST) Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA18567 for ; Fri, 29 Mar 2002 08:27:32 -0500 (EST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id PAA12354 for ; Fri, 29 Mar 2002 15:27:28 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 12270; Fri Mar 29 15:26:45 2002 Date: Fri, 29 Mar 2002 15:26:43 +0200 From: Alan Barrett To: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? Message-ID: <20020329132643.GJ20086@apb.cequrux.com> References: <20020329000649.4DFBE2A4A@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020329000649.4DFBE2A4A@orchard.arlington.ma.us> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > > wouldn't there at least need to be a viable (more suitable) protocol > So, here are just a few of them: All your examples address the "what is the remote username" problem, which is not what ident is actually useful for (regardless of what the original ident spec might have said). None of them addresses what ident is actually useful for, which is the logging of connections that might later be subject to an investigation without also logging all connections. --apb (Alan Barrett) From rmeijer@xs4all.nl Sun Mar 31 19:47:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id TAA18003 for ; Sun, 31 Mar 2002 19:47:17 -0500 (EST) Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA26329 for ; Sun, 31 Mar 2002 19:47:17 -0500 (EST) Received: from xs3.xs4all.nl (rmeijer@xs3.xs4all.nl [194.109.6.44]) by mxzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g310l7X3029887; Mon, 1 Apr 2002 02:47:07 +0200 (CEST) Received: from localhost (rmeijer@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id CAA05425; Mon, 1 Apr 2002 02:47:06 +0200 (CEST) Date: Mon, 1 Apr 2002 02:47:06 +0200 (CEST) From: Rob J Meijer To: Alan Barrett cc: saag@mit.edu Subject: Re: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: <20020329132643.GJ20086@apb.cequrux.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Fri, 29 Mar 2002, Alan Barrett wrote: > On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > > > wouldn't there at least need to be a viable (more suitable) protocol > > So, here are just a few of them: > > All your examples address the "what is the remote username" problem, > which is not what ident is actually useful for (regardless of what the > original ident spec might have said). > > None of them addresses what ident is actually useful for, which is the > logging of connections that might later be subject to an investigation > without also logging all connections. I agree fully with this point, and ident might not be verry good at this task for many reasons, but as it aparently currently is the only protocol with PS status, it seems not the right thing to move ident to historic before a protocol that does makes it to PS. An ident type TCP option would seem like the most logical 'replacement' possibility for ident, if we were to put some effort in creating a simple replacement for ident, than, if this replacement makes it to PS, that would be a good time to talk about moving ident to historic, not any time before that point. Rob J Meijer From stephen.farrell@baltimore.ie Thu Apr 4 07:43:08 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id HAA10718 for ; Thu, 4 Apr 2002 07:43:07 -0500 (EST) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA29536 for ; Thu, 4 Apr 2002 07:43:06 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g34Ch6b18329 for ; Thu, 4 Apr 2002 13:43:06 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 4 Apr 2002 13:37:46 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA16409; Thu, 4 Apr 2002 13:43:01 +0100 Message-ID: <3CAC4A57.FA27780C@baltimore.ie> Date: Thu, 04 Apr 2002 13:43:03 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: xme , Shivaram Mysore Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [saag] xkms requirements document last call Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hi, This mail is to ask for your comments on the W3C XKMS requirements document. See below for details. Sorry for the short notice - however, we will welcome comments for a while after the official end of the last-call period. Thanks, Stephen. On behalf of the W3C XML Key Managment Service WG [1], we are pleased to announce the publication of the "XKMS Requirements" Last Call Working Draft. This is one of the deliverables of the WG. The document address is: http://www.w3.org/TR/xkms2-req Abstract This document lists the design principles, scope and requirements for XML Key Management specifications and trust server key management implementations. It includes requirements as they relate to the key management syntax, processing, security and coordination with other standards activities. Status of this Document This is the Last Call for the requirements Working Draft of the XML Key Management Working Group (Activity Statement). This version represents the consensus of the Working Group. The last call period is 3 weeks, ending on 15 April 2002. Please send review comments by that date to the editors - fjh@alum.mit.edu, mike.just@entrust.com and cc: www-xkms@w3.org, shivaram.mysore@sun.com, stephen.farrell@baltimore.ie [1] http://www.w3.org/2001/XKMS -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From sh_sm_20@yahoo.com Sat Apr 6 04:52:07 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA13413 for ; Sat, 6 Apr 2002 04:52:07 -0500 (EST) Received: from web12802.mail.yahoo.com (web12802.mail.yahoo.com [216.136.174.37]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id EAA25529 for ; Sat, 6 Apr 2002 04:52:07 -0500 (EST) Message-ID: <20020406095206.77618.qmail@web12802.mail.yahoo.com> Received: from [212.118.14.37] by web12802.mail.yahoo.com via HTTP; Sat, 06 Apr 2002 01:52:06 PST Date: Sat, 6 Apr 2002 01:52:06 -0800 (PST) From: SHSM MNSY To: saag@mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [saag] (no subject) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: thanks __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From sh_sm_20@yahoo.com Sat Apr 6 04:52:44 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id EAA13418 for ; Sat, 6 Apr 2002 04:52:44 -0500 (EST) Received: from web12803.mail.yahoo.com (web12803.mail.yahoo.com [216.136.174.38]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id EAA25566 for ; Sat, 6 Apr 2002 04:52:43 -0500 (EST) Message-ID: <20020406095242.4263.qmail@web12803.mail.yahoo.com> Received: from [212.118.14.37] by web12803.mail.yahoo.com via HTTP; Sat, 06 Apr 2002 01:52:42 PST Date: Sat, 6 Apr 2002 01:52:42 -0800 (PST) From: SHSM MNSY To: saag@mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [saag] (no subject) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: mail Address : SH_SM_20@Yajhoo.com thanks __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From is3000sa@yahoo.com Sat Apr 6 11:57:48 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id LAA16758 for ; Sat, 6 Apr 2002 11:57:48 -0500 (EST) Received: from web20810.mail.yahoo.com (web20810.mail.yahoo.com [216.136.226.199]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id LAA03612 for ; Sat, 6 Apr 2002 11:57:47 -0500 (EST) Message-ID: <20020406165747.98078.qmail@web20810.mail.yahoo.com> Received: from [212.33.194.165] by web20810.mail.yahoo.com via HTTP; Sat, 06 Apr 2002 08:57:47 PST Date: Sat, 6 Apr 2002 08:57:47 -0800 (PST) From: s m To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-771920428-1018112267=:97837" Subject: [saag] (no subject) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: --0-771920428-1018112267=:97837 Content-Type: text/plain; charset=us-ascii is3000sa@yahoo.com --------------------------------- Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax --0-771920428-1018112267=:97837 Content-Type: text/html; charset=us-ascii is3000sa@yahoo.com   


Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax --0-771920428-1018112267=:97837-- From dhc2@dcrocker.net Sat Apr 6 14:32:35 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id OAA18362 for ; Sat, 6 Apr 2002 14:32:35 -0500 (EST) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA24146 for ; Sat, 6 Apr 2002 14:32:34 -0500 (EST) Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA29285 for ; Sat, 6 Apr 2002 11:32:32 -0800 Message-Id: <5.1.0.14.2.20020406110009.03566da8@127.0.0.1> X-Sender: dhc2@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 06 Apr 2002 11:31:44 -0800 To: From: Dave Crocker Subject: RE: [saag] move IDENT (rfc1413) to HISTORIC? In-Reply-To: <037a01c1d885$fcd60920$b73b68c0@A30P> References: <20020328135053.9104C2A4A@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 07:06 PM 3/28/2002 -0500, Steve Crocker wrote: > The first >controversial issue was whether it added any real security and, as a >collateral matter, whether it would tend to mislead people into thinking it >provided more security than it does. The first question, itself, highlights a deeper confusion that is probably the core of controversy about IDENT. IDENT passes some information that is not part of core network operations. As such it is application-level protocol. For such protocols we worry about semantics and maybe efficacy, as distinct from surrounding control and performance issues. If one says that IDENT is a security protocol, then its safety and degree of protection is literally central. Oddly that will also tend to obscure concerns over the core information issues. If one says that IDENT is a mechanism for permitting a remote host to report its connection-related information, then the protocol is similar to WHOIS and even LDAP. Security becomes a derivative issue, no matter how important. Although there are proponents of IDENT who view it as a formal security protocol, the proponents in this latest exchange talk as if it is just another information-passing protocol. (I happen to prefer that view, too.) Opponents are focusing on the security related inadequacies of IDENT and dangers that derive from those inadequacies. In other words, they are focusing on it as primarily being a security protocol. Since that was the view of the protocols original proponents, one cannot fault the critics. But it is time to move on and look at the real nature and use of the protocol. If we view IDENT as an information-passing protocol, then we divide debate into to areas. One is information efficacy, for which we have plenty of testimonials already. The second is security concerns. Security is always a fun topic in the IETF, particularly given that we have 12 years of high-quality security specifications that mostly have tiny deployment and use. Note that we have a number of core application protocols that are in wide use, in spite of atrocious security. Do we need to fix the security problems? Sure. Does that mean that we need to deprecate all application protocols that fail the security sniff test when not run with "proper" security controls? If the answer is yes then let's say goodbye to email, whois and ftp. >If the protocol is genuinely not being used, then indeed it's time to retire >it to HISTORIC. We know it is being used. Perhaps that is not enough. The concern about misunderstanding the utility and weakness of the protocol suggests making sure that the specification discusses both of these points carefully. (That's not to say it already does not, but to suggest where to focus evaluation of the current text.) At 11:30 PM 3/30/2002 -0800, Philip J. Nesser II wrote: >I hate to say this, but the *process* has problems. I don't want to see >the IESG overloaded with dozens of requests to reclassify older RFCs to >different status, but we need to clean this mess up. Exactly right. Either do away with additional levels or make them mean something significant to the real world. The latter will, by definition, ensure the incentive needed to get advocates for advancement. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From leeno_hamoudeh@hotmail.com Mon Apr 8 16:06:30 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id QAA16642 for ; Mon, 8 Apr 2002 16:06:30 -0400 (EDT) Received: from hotmail.com (f128.sea1.hotmail.com [207.68.163.128]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA06317 for ; Mon, 8 Apr 2002 16:06:29 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Apr 2002 13:06:28 -0700 Received: from 217.144.8.254 by sea1fd.sea1.hotmail.msn.com with HTTP; Mon, 08 Apr 2002 20:06:28 GMT X-Originating-IP: [217.144.8.254] From: "leen hamoudeh" To: saag@mit.edu Date: Mon, 08 Apr 2002 23:06:28 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Apr 2002 20:06:28.0441 (UTC) FILETIME=[DE55C490:01C1DF38] Subject: [saag] .......... Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From azinin@nexsi.com Wed Apr 10 21:00:05 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id VAA05172 for ; Wed, 10 Apr 2002 21:00:05 -0400 (EDT) Received: from chrome.nexsi.com (system149.nexsi.com [66.35.207.149]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA13204 for ; Wed, 10 Apr 2002 21:00:04 -0400 (EDT) Received: from khonsu.Winnet.NEXSI.NET (khonsu.winnet.nexsi.net [192.168.104.132]) by chrome.nexsi.com (Postfix) with ESMTP id 5D85EF02E; Wed, 10 Apr 2002 17:59:54 -0700 (PDT) Date: Wed, 10 Apr 2002 17:56:07 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.60c) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <7112958706.20020410175607@nexsi.com> To: saag@mit.edu Cc: Bill Fenner In-Reply-To: <9929340759.20020409184238@nexsi.com> References: <9929340759.20020409184238@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: RPSEC BOF Mailing List Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: FYI below. We're hoping this group to become the forum for RTG-SEC interactions. Alex ===8<==============Forwarded message=============== > Date: Tue, 9 Apr 2002 18:42:38 -0700 > From: Alex Zinin > Reply-To: Alex Zinin , > Bill Fenner > To: routing-discussion@ietf.org > Cc: riw@cisco.com > Subject: RPSEC BOF Mailing List > Folks: > As you know we had an RPSEC BOF meeting in Minneapolis. > We left the room with a consensus that a WG should be > formed, but a charter bashing is due. For more info > on the BOF, please visit the URL below. > http://www.ietf.org/ietf/02mar/rpsec.txt > The BOF chair (Russ, cc'ed) has set up a mailing list > for this effort, and we would like to encourage area > participants to subscribe to it and participate in > the discussion. The URL for the list is below: > http://www1.ietf.org/mailman/listinfo/rpsec > Thank you! > Alex & Bill > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of forwarded message=========== From Black_David@emc.com Fri Apr 19 12:55:30 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id MAA25648 for ; Fri, 19 Apr 2002 12:55:30 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA22454 for ; Fri, 19 Apr 2002 12:55:29 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3JGtSm21738 for ; Fri, 19 Apr 2002 12:55:28 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g3JGtS729567 for ; Fri, 19 Apr 2002 12:55:28 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <2P2TFJB5>; Fri, 19 Apr 2002 12:54:42 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E029377E3@CORPMX14> To: saag@mit.edu Date: Fri, 19 Apr 2002 12:54:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1E7C2.E1E61AF0" Subject: [saag] FW: I-D ACTION:draft-black-ips-iscsi-dhchap-01.txt Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1E7C2.E1E61AF0 Content-Type: text/plain; charset="iso-8859-1" FYI - this is the mechanism being considered in the IP Storage (ips) WG as a possible alternative to SRP for iSCSI. Concerns/issues with this draft should probably go to the IPS list (ips@ece.cmu.edu). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, April 19, 2002 7:22 AM Cc: ips@ece.cmu.edu Subject: I-D ACTION:draft-black-ips-iscsi-dhchap-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI Author(s) : D. Black Filename : draft-black-ips-iscsi-dhchap-01.txt Pages : 15 Date : 18-Apr-02 This draft describes an authentication mechanism based on enhancing CHAP [RFC 1994] with a Diffie-Hellman Exchange (see Section 22.1 of [Schneier] in order to prevent a passive eavesdropper from acquiring sufficient information to perform an off-line dictionary attack on the CHAP secret. The use of this authentication mechanism with iSCSI [iSCSI] is discussed, along with a brief comparison to the existing CHAP and SRP authentication mechanisms in iSCSI. Caution should be exercised in drawing inferences from the fact that the author of this draft is one of the chairs of the IP Storage Working Group. This draft is an individual submission that the IP Storage Working Group is free to adopt, modify, reject, fold, spindle, and/or mutilate as it sees fit. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-black-ips-iscsi-dhchap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-black-ips-iscsi-dhchap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-black-ips-iscsi-dhchap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C1E7C2.E1E61AF0 Content-Type: message/rfc822 To: Subject: Date: Fri, 19 Apr 2002 12:54:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1E7C2.E1E61AF0" ------_=_NextPart_002_01C1E7C2.E1E61AF0 Content-Type: text/plain ------_=_NextPart_002_01C1E7C2.E1E61AF0 Content-Type: application/octet-stream; name="ATT57059" Content-Disposition: attachment; filename="ATT57059" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418140853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-black-ips-iscsi-dhchap-01.txt ------_=_NextPart_002_01C1E7C2.E1E61AF0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-black-ips-iscsi-dhchap-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1E7C2.E1E61AF0-- ------_=_NextPart_000_01C1E7C2.E1E61AF0-- From mcr@sandelman.ottawa.on.ca Fri Apr 19 14:53:22 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id OAA27574 for ; Fri, 19 Apr 2002 14:53:22 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA10102 for ; Fri, 19 Apr 2002 14:53:21 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g3JIrqi13494 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 19 Apr 2002 14:53:54 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g3JIpcm15276; Fri, 19 Apr 2002 14:51:40 -0400 (EDT) Message-Id: <200204191851.g3JIpcm15276@marajade.sandelman.ottawa.on.ca> To: Black_David@emc.com cc: saag@mit.edu Subject: Re: [saag] FW: I-D ACTION:draft-black-ips-iscsi-dhchap-01.txt In-reply-to: Your message of "Fri, 19 Apr 2002 12:54:34 EDT." <277DD60FB639D511AC0400B0D068B71E029377E3@CORPMX14> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 19 Apr 2002 14:51:37 -0400 From: Michael Richardson Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >>>>> "Black" == Black David writes: Black> FYI - this is the mechanism being considered in the IP Storage (ips) Black> WG as a possible alternative to SRP for iSCSI. Concerns/issues with Black> this draft should probably go to the IPS list (ips@ece.cmu.edu). And this differs from IKE, how? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From Todd_Sperry@adaptec.com Fri Apr 19 15:21:29 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id PAA28011 for ; Fri, 19 Apr 2002 15:21:29 -0400 (EDT) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22060 for ; Fri, 19 Apr 2002 15:21:28 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g3JJLNj03660; Fri, 19 Apr 2002 12:21:23 -0700 (PDT) Received: from aimexc06.corp.adaptec.com (aimexc06.corp.adaptec.com [162.62.62.46]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id MAA22019; Fri, 19 Apr 2002 12:21:23 -0700 (PDT) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id <2L7G9HCC>; Fri, 19 Apr 2002 12:16:59 -0700 Message-ID: From: "Sperry, Todd" To: "'Michael Richardson'" , Black_David@emc.com Cc: saag@mit.edu Subject: RE: [saag] FW: I-D ACTION:draft-black-ips-iscsi-dhchap-01.txt Date: Fri, 19 Apr 2002 12:16:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: One difference is that the DH exchange is not authenticated. From the beginning of the draft... >DH-CHAP is a new combination of an unauthenticated Diffie-Hellman >(DH) key exchange (see Section 22.1 of [Schneier]) with the >existing CHAP algorithm [RFC 1994]. Thanks, Todd. -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Friday, April 19, 2002 11:52 AM To: Black_David@emc.com Cc: saag@mit.edu Subject: Re: [saag] FW: I-D ACTION:draft-black-ips-iscsi-dhchap-01.txt >>>>> "Black" == Black David writes: Black> FYI - this is the mechanism being considered in the IP Storage (ips) Black> WG as a possible alternative to SRP for iSCSI. Concerns/issues with Black> this draft should probably go to the IPS list (ips@ece.cmu.edu). And this differs from IKE, how? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ _______________________________________________ saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag From mcr@sandelman.ottawa.on.ca Fri Apr 19 17:13:51 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id RAA29947 for ; Fri, 19 Apr 2002 17:13:51 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA04803 for ; Fri, 19 Apr 2002 17:13:50 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g3JLEMi13686 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 19 Apr 2002 17:14:26 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g3JLC3F16772; Fri, 19 Apr 2002 17:12:09 -0400 (EDT) Message-Id: <200204192112.g3JLC3F16772@marajade.sandelman.ottawa.on.ca> To: "Sperry, Todd" cc: Black_David@emc.com, saag@mit.edu Subject: Re: [saag] FW: I-D ACTION:draft-black-ips-iscsi-dhchap-01.txt In-reply-to: Your message of "Fri, 19 Apr 2002 12:16:58 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 19 Apr 2002 17:12:02 -0400 From: Michael Richardson Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: >>>>> "Sperry," == Sperry, Todd writes: Sperry,> One difference is that the DH exchange is not authenticated. >> From the beginning of the draft... >> DH-CHAP is a new combination of an unauthenticated Diffie-Hellman >> (DH) key exchange (see Section 22.1 of [Schneier]) with the >> existing CHAP algorithm [RFC 1994]. I see. It seems that IKE with shared secrets is essentially the same thing. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From slh7@gmx.net Sun Apr 21 03:57:17 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id DAA24549 for ; Sun, 21 Apr 2002 03:57:17 -0400 (EDT) From: slh7@gmx.net Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id DAA20504 for ; Sun, 21 Apr 2002 03:57:16 -0400 (EDT) Received: (qmail 13859 invoked by uid 0); 21 Apr 2002 07:57:15 -0000 Date: Sun, 21 Apr 2002 09:57:15 +0200 (MEST) To: saag@mit.edu MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated-Sender: #0013934902@gmx.net X-Authenticated-IP: [217.52.10.3] Message-ID: <21698.1019375835@www49.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [saag] remove me from the list Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: remove me from the list -- ----------------------------- Salah Aly; Teaching Assistant, Computer Science; Phone: 00202 565 2775 http://www.crypto.8m.com ----------------------------- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From dong_wei@tsinghua.com Thu May 23 15:05:20 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id PAA24941 for ; Thu, 23 May 2002 15:05:20 -0400 (EDT) Received: from omta05.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA09949 for ; Thu, 23 May 2002 15:05:19 -0400 (EDT) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta05.mta.everyone.net (Postfix) with ESMTP id 58C0E48F1C; Thu, 23 May 2002 12:05:19 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 2FFB93ECC; Thu, 23 May 2002 12:05:19 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Thu, 23 May 2002 12:05:18 -0700 (PDT) From: Dong To: Security_Area_Advisory_Group , IPsec Reply-To: dong_wei@tsinghua.com X-Originating-Ip: [128.235.249.42] Message-Id: <20020523190519.2FFB93ECC@sitemail.everyone.net> Subject: [saag] Secure QoS Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hi, I am trying to do a survey on Secure QoS. Any paper on that? Thx. Dong _____________________________________________________________ Get Tsinghua University free email account: www.tsinghua.com Web site sponsored and hosted by AtFreeWeb.com _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From dong_wei@tsinghua.com Thu May 23 19:46:10 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id TAA00201 for ; Thu, 23 May 2002 19:46:10 -0400 (EDT) Received: from omta04.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA17846 for ; Thu, 23 May 2002 19:46:09 -0400 (EDT) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta04.mta.everyone.net (Postfix) with ESMTP id 6C0224F9AB; Thu, 23 May 2002 16:46:09 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 3FA1B2756; Thu, 23 May 2002 16:46:09 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Thu, 23 May 2002 16:46:08 -0700 (PDT) From: Dong To: IPsec , Security_Area_Advisory_Group Reply-To: dong_wei@tsinghua.com X-Originating-Ip: [128.235.249.42] Message-Id: <20020523234609.3FA1B2756@sitemail.everyone.net> Subject: [saag] (no subject) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Roy, I just read a paper "Preventing Denial of Service Attacks on Quality of Service", which is written by some guys from N.C. State university and UC Davis. The service quality to legimative users could be degraded by attacks on control flow or data flow. For example, an illegal user can forge a reservation message, so he can receive an unauthorized amount of resources. I just wanna to know what threats exist in providing QoS, and what the state-of-art techniques to prevent, detect and counter those attacks, and of course recovery mothods as well. Thx a lot. Dong Dong, Please be a little more precise in what you are asking for, i.e. 3-5 bullet list items on what kind of security you seek. Roy -----Original Message----- From: Dong [mailto:dong_wei@tsinghua.com] Sent: Thursday, May 23, 2002 2:05 PM To: Security_Area_Advisory_Group; IPsec Subject: Secure QoS Hi, I am trying to do a survey on Secure QoS. Any paper on that? Thx. Dong _____________________________________________________________ Get Tsinghua University free email account: www.tsinghua.com Web site sponsored and hosted by AtFreeWeb.com _____________________________________________________________ Get Tsinghua University free email account: www.tsinghua.com Web site sponsored and hosted by AtFreeWeb.com _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From Black_David@emc.com Thu May 23 20:19:16 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id UAA01000 for ; Thu, 23 May 2002 20:19:16 -0400 (EDT) From: Black_David@emc.com Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA20679 for ; Thu, 23 May 2002 20:19:15 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 20:18:01 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937936@CORPMX14> To: dong_wei@tsinghua.com, saag@mit.edu Subject: RE: [saag] (no subject) Date: Thu, 23 May 2002 20:17:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: One place to start would be the Security Considerations sections of the QoS RFCs for the QoS techniques that you are interested in along with any material in the rest of those RFCs that discusses of security mechanisms/protocols/ techniques/etc. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Dong [mailto:dong_wei@tsinghua.com] > Sent: Thursday, May 23, 2002 7:46 PM > To: IPsec; Security_Area_Advisory_Group > Subject: [saag] (no subject) > > > Roy, > > I just read a paper "Preventing Denial of Service Attacks on > Quality of Service", which is written by some guys from N.C. > State university and UC Davis. The service quality to > legimative users could be degraded by attacks on control flow > or data flow. For example, an illegal user can forge a > reservation message, so he can receive an unauthorized amount > of resources. I just wanna to know what threats exist in > providing QoS, and what the state-of-art techniques to > prevent, detect and counter those attacks, and of course > recovery mothods as well. > > Thx a lot. > > Dong > > > Dong, > Please be a little more precise in what you are asking for, i.e. > > 3-5 bullet list items on what kind of security you seek. > > Roy > > -----Original Message----- > From: Dong [mailto:dong_wei@tsinghua.com] > Sent: Thursday, May 23, 2002 2:05 PM > To: Security_Area_Advisory_Group; IPsec > Subject: Secure QoS > > > Hi, > > I am trying to do a survey on Secure QoS. Any paper on that? Thx. > > Dong > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Promote your group and strengthen ties to your members with > email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > From warlord@MIT.EDU Fri May 24 23:03:29 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id XAA26588 for ; Fri, 24 May 2002 23:03:28 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA16539; Fri, 24 May 2002 23:03:26 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA28778; Fri, 24 May 2002 23:03:26 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA07070; Fri, 24 May 2002 23:00:52 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA14164; Fri, 24 May 2002 23:00:52 -0400 (EDT) To: SatishK Amara Cc: dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group References: <20020524143641.97990.qmail@web21302.mail.yahoo.com> From: Derek Atkins Date: 24 May 2002 23:00:52 -0400 In-Reply-To: <20020524143641.97990.qmail@web21302.mail.yahoo.com> Message-ID: Lines: 86 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [saag] Re: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Because IPsec is hop-by-hop but you want RSVP end-to-end. -derek SatishK Amara writes: > Why don't you use IPSEC to secure RSVP. > > Satish Amara > --- Dong wrote: > > Roy, > > > > I just read a paper "Preventing Denial of Service > > Attacks on Quality of Service", which is written by > > some guys from N.C. State university and UC Davis. > > The service quality to legimative users could be > > degraded by attacks on control flow or data flow. > > For example, an illegal user can forge a reservation > > message, so he can receive an unauthorized amount of > > resources. I just wanna to know what threats exist > > in providing QoS, and what the state-of-art > > techniques to prevent, detect and counter those > > attacks, and of course recovery mothods as well. > > > > Thx a lot. > > > > Dong > > > > > > Dong, > > Please be a little more precise in what you are > > asking for, i.e. > > > > 3-5 bullet list items on what kind of security you > > seek. > > > > Roy > > > > -----Original Message----- > > From: Dong [mailto:dong_wei@tsinghua.com] > > Sent: Thursday, May 23, 2002 2:05 PM > > To: Security_Area_Advisory_Group; IPsec > > Subject: Secure QoS > > > > > > Hi, > > > > I am trying to do a survey on Secure QoS. Any paper > > on that? Thx. > > > > Dong > > > > > _____________________________________________________________ > > Get Tsinghua University free email account: > > www.tsinghua.com > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > _____________________________________________________________ > > Get Tsinghua University free email account: > > www.tsinghua.com > > Web site sponsored and hosted by AtFreeWeb.com > > > > > _____________________________________________________________ > > Promote your group and strengthen ties to your > > members with email@yourgroup.org by Everyone.net > http://www.everyone.net/?btn=tag > > > ===== > In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com -- 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 rja@extremenetworks.com Sat May 25 10:53:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id KAA06528 for ; Sat, 25 May 2002 10:53:27 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA18986; Sat, 25 May 2002 10:53:26 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 4F6EC67103; Sat, 25 May 2002 11:25:43 -0400 (EDT) Date: Sat, 25 May 2002 10:53:22 -0400 Subject: Re: [saag] Re: Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: SatishK Amara , dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group To: Derek Atkins From: RJ Atkinson In-Reply-To: Message-Id: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Friday, May 24, 2002, at 11:00 , Derek Atkins wrote: > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > -derek Hmm. I would rather say that RSVP is hop-by-hop and that (normally) AH/ESP are end-to-end. However, if one used (for example) AH with an asymmetric algorithm, one could perform hop-by-hop authentication of the packet with AH. This has obvious computational cost issues so might not be the best choice. > SatishK Amara writes: > >> Why don't you use IPSEC to secure RSVP. >> >> Satish Amara From mshore@cisco.com Sat May 25 11:13:19 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id LAA06950 for ; Sat, 25 May 2002 11:13:19 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA03035; Sat, 25 May 2002 11:13:18 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4PFDGIZ026746; Sat, 25 May 2002 08:13:16 -0700 (PDT) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADZ05713; Sat, 25 May 2002 08:10:20 -0700 (PDT) Message-Id: <5.1.0.14.0.20020525111240.00ac5c40@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 25 May 2002 11:17:54 -0400 To: RJ Atkinson , Derek Atkins From: Melinda Shore Subject: Re: [saag] Re: Cc: SatishK Amara , dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group In-Reply-To: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote: >Hmm. I would rather say that RSVP is hop-by-hop and >that (normally) AH/ESP are end-to-end. In terms of addressing, RSVP is end-to-end in one direction (sender->receiver) and hop-by-hop in the other (receiver->sender). >However, if one used (for example) AH with an asymmetric algorithm, >one could perform hop-by-hop authentication of the >packet with AH. This has obvious computational cost >issues so might not be the best choice. The packet payload is going to be modified at each hop, as well, in both directions. Melinda From rkopeikin@lucent.com Thu May 23 17:08:26 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id RAA27483 for ; Thu, 23 May 2002 17:08:26 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02055 for ; Thu, 23 May 2002 17:08:26 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4NL8Px02518 for ; Thu, 23 May 2002 17:08:25 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 16:08:24 -0500 Message-ID: <80B684C5E29FD211AA8000A0C9CDD9190CE5A231@il0015exch005u.ih.lucent.com> From: "Kopeikin, Roy A (Roy)" To: dong_wei@tsinghua.com, Security_Area_Advisory_Group , IPsec Date: Thu, 23 May 2002 16:08:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [saag] RE: Secure QoS Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Dong, Please be a little more precise in what you are asking for, i.e. 3-5 bullet list items on what kind of security you seek. Roy -----Original Message----- From: Dong [mailto:dong_wei@tsinghua.com] Sent: Thursday, May 23, 2002 2:05 PM To: Security_Area_Advisory_Group; IPsec Subject: Secure QoS Hi, I am trying to do a survey on Secure QoS. Any paper on that? Thx. Dong _____________________________________________________________ Get Tsinghua University free email account: www.tsinghua.com Web site sponsored and hosted by AtFreeWeb.com _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From wu@cs.ucdavis.edu Thu May 23 20:20:59 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id UAA01013 for ; Thu, 23 May 2002 20:20:59 -0400 (EDT) Received: from soda.cs.ucdavis.edu (soda.cs.ucdavis.edu [169.237.6.187]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA26493 for ; Thu, 23 May 2002 20:20:58 -0400 (EDT) Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.9.3+Sun/8.9.3/CS UCDavis) with ESMTP id RAA28345; Thu, 23 May 2002 17:20:51 -0700 (PDT) Message-ID: <3CED86D4.116A78F4@cs.ucdavis.edu> Date: Thu, 23 May 2002 17:18:28 -0700 From: "S. Felix Wu" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: dong_wei@tsinghua.com CC: IPsec , Security_Area_Advisory_Group References: <20020523234609.3FA1B2756@sitemail.everyone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [saag] Re: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I am a co-author of the paper you mentioned. I feel that the subject of Secure QoS (or QoS security) is not very related to the core interest of the IPsec working group. (maybe more related to DiffServ.) In the ArQos project (http://arqos.csc.ncsu.edu), we are concerning attackers stealing the bandwidth, one way or the other (i.e, via control plane or data plane). Publications can be found there. However, DoS concern for IKE (or IKEv2 and JFK) might be relevent for this working group as many messages have been posted here lately. -Felix Dong wrote: > > Roy, > > I just read a paper "Preventing Denial of Service Attacks on Quality of Service", which is written by some guys from N.C. State university and UC Davis. The service quality to legimative users could be degraded by attacks on control flow or data flow. For example, an illegal user can forge a reservation message, so he can receive an unauthorized amount of resources. I just wanna to know what threats exist in providing QoS, and what the state-of-art techniques to prevent, detect and counter those attacks, and of course recovery mothods as well. > > Thx a lot. > > Dong > > Dong, > Please be a little more precise in what you are asking for, i.e. > > 3-5 bullet list items on what kind of security you seek. > > Roy > > -----Original Message----- > From: Dong [mailto:dong_wei@tsinghua.com] > Sent: Thursday, May 23, 2002 2:05 PM > To: Security_Area_Advisory_Group; IPsec > Subject: Secure QoS > > Hi, > > I am trying to do a survey on Secure QoS. Any paper on that? Thx. > > Dong > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From kumar_amara@yahoo.com Fri May 24 10:36:47 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id KAA13678 for ; Fri, 24 May 2002 10:36:46 -0400 (EDT) Received: from web21302.mail.yahoo.com (web21302.mail.yahoo.com [216.136.173.210]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id KAA29052 for ; Fri, 24 May 2002 10:36:44 -0400 (EDT) Message-ID: <20020524143641.97990.qmail@web21302.mail.yahoo.com> Received: from [149.112.94.169] by web21302.mail.yahoo.com via HTTP; Fri, 24 May 2002 07:36:41 PDT Date: Fri, 24 May 2002 07:36:41 -0700 (PDT) From: SatishK Amara To: dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group In-Reply-To: <20020523234609.3FA1B2756@sitemail.everyone.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [saag] Re: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Why don't you use IPSEC to secure RSVP. Satish Amara --- Dong wrote: > Roy, > > I just read a paper "Preventing Denial of Service > Attacks on Quality of Service", which is written by > some guys from N.C. State university and UC Davis. > The service quality to legimative users could be > degraded by attacks on control flow or data flow. > For example, an illegal user can forge a reservation > message, so he can receive an unauthorized amount of > resources. I just wanna to know what threats exist > in providing QoS, and what the state-of-art > techniques to prevent, detect and counter those > attacks, and of course recovery mothods as well. > > Thx a lot. > > Dong > > > Dong, > Please be a little more precise in what you are > asking for, i.e. > > 3-5 bullet list items on what kind of security you > seek. > > Roy > > -----Original Message----- > From: Dong [mailto:dong_wei@tsinghua.com] > Sent: Thursday, May 23, 2002 2:05 PM > To: Security_Area_Advisory_Group; IPsec > Subject: Secure QoS > > > Hi, > > I am trying to do a survey on Secure QoS. Any paper > on that? Thx. > > Dong > > _____________________________________________________________ > Get Tsinghua University free email account: > www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > > > _____________________________________________________________ > Get Tsinghua University free email account: > www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Promote your group and strengthen ties to your > members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag ===== In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From Ariel_Waissbein@corest.com Fri May 24 14:35:48 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id OAA18082 for ; Fri, 24 May 2002 14:35:48 -0400 (EDT) Received: from sin.core-sdi.com (sin.core-sdi.com [200.49.71.179]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA26232 for ; Fri, 24 May 2002 14:35:46 -0400 (EDT) Received: from petawilson (unknown [192.168.66.32]) by mail.servers.core-sdi.com (nice mail system) with SMTP id D4E7239D96D; Fri, 24 May 2002 15:35:44 -0300 (ART) Message-ID: <006201c20352$bbb68da0$2042a8c0@petawilson> From: "Ariel Waissbein" To: , "Security_Area_Advisory_Group" References: <20020523190519.2FFB93ECC@sitemail.everyone.net> Subject: Re: [saag] Secure QoS Date: Fri, 24 May 2002 15:42:18 -0300 Organization: CORE Security Technologies MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: I have just found this http://arqos.csc.ncsu.edu/papers.htm haven't checked it, though. Ariel ----- Original Message ----- From: "Dong" To: "Security_Area_Advisory_Group" ; "IPsec" Sent: Thursday, May 23, 2002 4:05 PM Subject: [saag] Secure QoS > Hi, > > I am trying to do a survey on Secure QoS. Any paper on that? Thx. > > Dong > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag From warlord@MIT.EDU Wed May 29 09:43:21 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA02641 for ; Wed, 29 May 2002 09:43:21 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA11975; Wed, 29 May 2002 09:43:18 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA21200; Wed, 29 May 2002 09:43:17 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA06674; Wed, 29 May 2002 09:43:16 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA25756; Wed, 29 May 2002 09:43:16 -0400 (EDT) To: "Hannes Tschofenig" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" From: Derek Atkins References: Date: 29 May 2002 09:43:16 -0400 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [saag] Re: IPsec and RSVP Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: "Hannes Tschofenig" writes: > hi > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > capable router)? You lose the authentication of the end-point requesting the reservation. If you use ipsec in this way, then each router knows its peer, but you have no transitive authentication. The only protection you get is protection of on-the-wire request. You have no protection against a corrupt router along the path, or indeed no way to know what the actual original request was. > ciao > hannes -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From mshore@cisco.com Wed May 29 09:43:59 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA02662 for ; Wed, 29 May 2002 09:43:59 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA10377 for ; Wed, 29 May 2002 09:43:59 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4TDhrIZ006368; Wed, 29 May 2002 06:43:54 -0700 (PDT) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADZ60240; Wed, 29 May 2002 06:40:58 -0700 (PDT) Message-Id: <5.1.0.14.0.20020529094532.00ab6b90@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 May 2002 09:48:37 -0400 To: "Hannes Tschofenig" From: Melinda Shore Subject: RE: [saag] Re: Cc: "IPsec" , "Security_Area_Advisory_Group" In-Reply-To: References: <5.1.0.14.0.20020525111240.00ac5c40@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 03:43 PM 5/29/02 +0200, Hannes Tschofenig wrote: >rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other >(except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP >is end-to-end in one direction (sender->receiver)" confuses me somehow. the >security for rsvp is build on hop-by-hop security based on a chain-of-trust. In the sender->receiver direction, the destination IP address in the Path message is the receiver's. In the receiver-> sender direction, the destination IP address in the Resv message is the address of the PHOP that was picked up by the Path message. Melinda From warlord@MIT.EDU Wed May 29 09:45:43 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA02753 for ; Wed, 29 May 2002 09:45:43 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA10911; Wed, 29 May 2002 09:45:35 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA21648; Wed, 29 May 2002 09:45:34 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA25813; Wed, 29 May 2002 09:45:33 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA25759; Wed, 29 May 2002 09:45:33 -0400 (EDT) To: "Hannes Tschofenig" Cc: "Melinda Shore" , "RJ Atkinson" , "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" From: Derek Atkins Subject: Re: [saag] Re: IPsec and RSVP References: Date: 29 May 2002 09:45:33 -0400 In-Reply-To: Message-ID: Lines: 57 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: And we're saying that this chain-of-trust is a bad model, because anyone close to an edge can inject any amount of bogus data into the network. Once it's injected, it's even TRUSTED! One major problem is that you lose the origin of the request after the first hop, not to mention the actual request itself. -derek "Hannes Tschofenig" writes: > hi > > what do you mean by "in terms of addressing"? > > my understanding of rsvp is: > rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other > (except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP > is end-to-end in one direction (sender->receiver)" confuses me somehow. the > security for rsvp is build on hop-by-hop security based on a chain-of-trust. > > ciao > hannes > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore > > Sent: Saturday, May 25, 2002 5:18 PM > > To: RJ Atkinson; Derek Atkins > > Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec; > > Security_Area_Advisory_Group > > Subject: Re: [saag] Re: > > > > > > At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote: > > >Hmm. I would rather say that RSVP is hop-by-hop and > > >that (normally) AH/ESP are end-to-end. > > > > In terms of addressing, RSVP is end-to-end in one > > direction (sender->receiver) and hop-by-hop in the > > other (receiver->sender). > > > > >However, if one used (for example) AH with an asymmetric algorithm, > > >one could perform hop-by-hop authentication of the > > >packet with AH. This has obvious computational cost > > >issues so might not be the best choice. > > > > The packet payload is going to be modified at each hop, > > as well, in both directions. > > > > Melinda > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From mshore@cisco.com Wed May 29 10:02:12 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id KAA03307 for ; Wed, 29 May 2002 10:02:12 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA17554 for ; Wed, 29 May 2002 10:02:11 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4TE1tuF029092; Wed, 29 May 2002 07:01:55 -0700 (PDT) Received: from spandex.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADZ60565; Wed, 29 May 2002 06:59:12 -0700 (PDT) Message-Id: <5.1.0.14.0.20020529100110.00aad1b0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 May 2002 10:06:51 -0400 To: "Hannes Tschofenig" From: Melinda Shore Subject: RE: [saag] Re: Cc: "IPsec" , "Security_Area_Advisory_Group" In-Reply-To: References: <5.1.0.14.0.20020529094532.00ab6b90@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote: >do you think that the hop-by-hop security in rsvp is a good or a bad thing? >should there be more than what is currently provided? There needs to be more than what is currently provided, but, as always, there's a big keying/cert problem, particularly in a multi-"domain" environment. I don't think the threat environment is particularly well-understood (I've seen your NSIS draft but haven't gone through it in detail). Clearly IPSec is not the right answer for Path messages, however, because while the addressing is end-to-end the payload contents do change as the packet transits participating routers. Melinda From Hannes.Tschofenig@mchp.siemens.de Wed May 29 09:38:56 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA02511 for ; Wed, 29 May 2002 09:38:56 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA10349 for ; Wed, 29 May 2002 09:38:55 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g4TDcr522401; Wed, 29 May 2002 15:38:53 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TDcqF10411; Wed, 29 May 2002 15:38:52 +0200 (MEST) From: "Hannes Tschofenig" To: , "IPsec" , "Security_Area_Advisory_Group" Date: Wed, 29 May 2002 15:43:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020523234609.3FA1B2756@sitemail.everyone.net> Subject: [saag] qos threats Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi regarding threats you might read (and maybe comment) a threat draft related to nsis; see: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-00.txt ciao hannes ps: your comments are welcome. Title : NSIS Threats Author(s) : H. Tschofenig Filename : draft-tschofenig-nsis-threats-00.txt Pages : 9 Date : 24-May-02 As the work in the NSIS working has begun to describe requirements and the framework people started thinking about possible security implication. This document should provide a starting point for the discussion at the NSIS interim meeting and at the NSIS working group mailing list regarding the security issues that have to be addressed. It does not describe threats for a particular published protocol. This memo is furthermore meant to create awareness for the security within the group. The threat scenarios in this document are matched against the security requirements described in [1]. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dong > Sent: Friday, May 24, 2002 1:46 AM > To: IPsec; Security_Area_Advisory_Group > Subject: > > > Roy, > > I just read a paper "Preventing Denial of Service Attacks on > Quality of Service", which is written by some guys from N.C. > State university and UC Davis. The service quality to legimative > users could be degraded by attacks on control flow or data flow. > For example, an illegal user can forge a reservation message, so > he can receive an unauthorized amount of resources. I just wanna > to know what threats exist in providing QoS, and what the > state-of-art techniques to prevent, detect and counter those > attacks, and of course recovery mothods as well. > > Thx a lot. > > Dong > > > Dong, > Please be a little more precise in what you are asking for, i.e. > > 3-5 bullet list items on what kind of security you seek. > > Roy > > -----Original Message----- > From: Dong [mailto:dong_wei@tsinghua.com] > Sent: Thursday, May 23, 2002 2:05 PM > To: Security_Area_Advisory_Group; IPsec > Subject: Secure QoS > > > Hi, > > I am trying to do a survey on Secure QoS. Any paper on that? Thx. > > Dong > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Promote your group and strengthen ties to your members with > email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From Hannes.Tschofenig@mchp.siemens.de Wed May 29 09:38:58 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA02516 for ; Wed, 29 May 2002 09:38:58 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA08534 for ; Wed, 29 May 2002 09:38:56 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g4TDcs522412; Wed, 29 May 2002 15:38:54 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TDcrF10428; Wed, 29 May 2002 15:38:53 +0200 (MEST) From: "Hannes Tschofenig" To: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Date: Wed, 29 May 2002 15:43:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020524143641.97990.qmail@web21302.mail.yahoo.com> Subject: [saag] ipsec to secure rsvp Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi there is no reason why not to use ipsec to secure rsvp. especially in the core network (between routers) this might be a reasonable approach. using ipsec to secure the traffic between the application (end-host) and the first hop router is however more difficult. ciao hannes > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara > Sent: Friday, May 24, 2002 4:37 PM > To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > Subject: Re: > > > Why don't you use IPSEC to secure RSVP. > > Satish Amara > --- Dong wrote: > > Roy, > > > > I just read a paper "Preventing Denial of Service > > Attacks on Quality of Service", which is written by > > some guys from N.C. State university and UC Davis. > > The service quality to legimative users could be > > degraded by attacks on control flow or data flow. > > For example, an illegal user can forge a reservation > > message, so he can receive an unauthorized amount of > > resources. I just wanna to know what threats exist > > in providing QoS, and what the state-of-art > > techniques to prevent, detect and counter those > > attacks, and of course recovery mothods as well. > > > > Thx a lot. > > > > Dong > > > > > > Dong, > > Please be a little more precise in what you are > > asking for, i.e. > > > > 3-5 bullet list items on what kind of security you > > seek. > > > > Roy > > > > -----Original Message----- > > From: Dong [mailto:dong_wei@tsinghua.com] > > Sent: Thursday, May 23, 2002 2:05 PM > > To: Security_Area_Advisory_Group; IPsec > > Subject: Secure QoS > > > > > > Hi, > > > > I am trying to do a survey on Secure QoS. Any paper > > on that? Thx. > > > > Dong > > > > > _____________________________________________________________ > > Get Tsinghua University free email account: > > www.tsinghua.com > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > _____________________________________________________________ > > Get Tsinghua University free email account: > > www.tsinghua.com > > Web site sponsored and hosted by AtFreeWeb.com > > > > > _____________________________________________________________ > > Promote your group and strengthen ties to your > > members with email@yourgroup.org by Everyone.net > http://www.everyone.net/?btn=tag > > > ===== > In natural science, Nature has given us a world and we're just to > discover its laws. In computers, we can stuff laws into it and > create a world -- Alan Kay > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com From Hannes.Tschofenig@mchp.siemens.de Wed May 29 09:38:59 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA02521 for ; Wed, 29 May 2002 09:38:59 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA08547; Wed, 29 May 2002 09:38:57 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g4TDcth08140; Wed, 29 May 2002 15:38:55 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TDctF10463; Wed, 29 May 2002 15:38:55 +0200 (MEST) From: "Hannes Tschofenig" To: "RJ Atkinson" , "Derek Atkins" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: Date: Wed, 29 May 2002 15:43:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi > > On Friday, May 24, 2002, at 11:00 , Derek Atkins wrote: > > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > > > -derek > > Hmm. I would rather say that RSVP is hop-by-hop and > that (normally) AH/ESP are end-to-end. but no one prevents you from using ipsec ah/esp in a hop-by-hop mode for protecting rsvp. > > However, if one used (for example) AH with an asymmetric algorithm, > one could perform hop-by-hop authentication of the > packet with AH. what do you mean by "AH with an asymmetric algorithm" ? IKE with an asymmetric authentiction mode? > This has obvious computational cost > issues so might not be the best choice. ciao hannes > > > SatishK Amara writes: > > > >> Why don't you use IPSEC to secure RSVP. > >> > >> Satish Amara From Hannes.Tschofenig@mchp.siemens.de Wed May 29 09:39:00 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA02526 for ; Wed, 29 May 2002 09:38:59 -0400 (EDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA08556; Wed, 29 May 2002 09:38:58 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g4TDct518243; Wed, 29 May 2002 15:38:55 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TDcsF10448; Wed, 29 May 2002 15:38:54 +0200 (MEST) From: "Hannes Tschofenig" To: "Melinda Shore" , "RJ Atkinson" , "Derek Atkins" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: Date: Wed, 29 May 2002 15:43:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020525111240.00ac5c40@localhost> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi what do you mean by "in terms of addressing"? my understanding of rsvp is: rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other (except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP is end-to-end in one direction (sender->receiver)" confuses me somehow. the security for rsvp is build on hop-by-hop security based on a chain-of-trust. ciao hannes > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore > Sent: Saturday, May 25, 2002 5:18 PM > To: RJ Atkinson; Derek Atkins > Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec; > Security_Area_Advisory_Group > Subject: Re: [saag] Re: > > > At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote: > >Hmm. I would rather say that RSVP is hop-by-hop and > >that (normally) AH/ESP are end-to-end. > > In terms of addressing, RSVP is end-to-end in one > direction (sender->receiver) and hop-by-hop in the > other (receiver->sender). > > >However, if one used (for example) AH with an asymmetric algorithm, > >one could perform hop-by-hop authentication of the > >packet with AH. This has obvious computational cost > >issues so might not be the best choice. > > The packet payload is going to be modified at each hop, > as well, in both directions. > > Melinda From Hannes.Tschofenig@mchp.siemens.de Wed May 29 09:43:45 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA02648 for ; Wed, 29 May 2002 09:43:45 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA08541; Wed, 29 May 2002 09:38:56 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g4TDcs522422; Wed, 29 May 2002 15:38:55 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TDcsF10436; Wed, 29 May 2002 15:38:54 +0200 (MEST) From: "Hannes Tschofenig" To: "Derek Atkins" , "SatishK Amara" Cc: , "IPsec" , "Security_Area_Advisory_Group" Date: Wed, 29 May 2002 15:43:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: [saag] RE: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp capable router)? ciao hannes > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins > Sent: Saturday, May 25, 2002 5:01 AM > To: SatishK Amara > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > Subject: Re: > > > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > -derek > > SatishK Amara writes: > > > Why don't you use IPSEC to secure RSVP. > > > > Satish Amara > > --- Dong wrote: > > > Roy, > > > > > > I just read a paper "Preventing Denial of Service > > > Attacks on Quality of Service", which is written by > > > some guys from N.C. State university and UC Davis. > > > The service quality to legimative users could be > > > degraded by attacks on control flow or data flow. > > > For example, an illegal user can forge a reservation > > > message, so he can receive an unauthorized amount of > > > resources. I just wanna to know what threats exist > > > in providing QoS, and what the state-of-art > > > techniques to prevent, detect and counter those > > > attacks, and of course recovery mothods as well. > > > > > > Thx a lot. > > > > > > Dong > > > > > > > > > Dong, > > > Please be a little more precise in what you are > > > asking for, i.e. > > > > > > 3-5 bullet list items on what kind of security you > > > seek. > > > > > > Roy > > > > > > -----Original Message----- > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > Sent: Thursday, May 23, 2002 2:05 PM > > > To: Security_Area_Advisory_Group; IPsec > > > Subject: Secure QoS > > > > > > > > > Hi, > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > on that? Thx. > > > > > > Dong > > > > > > > > _____________________________________________________________ > > > Get Tsinghua University free email account: > > > www.tsinghua.com > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > _____________________________________________________________ > > > Get Tsinghua University free email account: > > > www.tsinghua.com > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > _____________________________________________________________ > > > Promote your group and strengthen ties to your > > > members with email@yourgroup.org by Everyone.net > > http://www.everyone.net/?btn=tag > > > > > > ===== > > In natural science, Nature has given us a world and we're just > to discover its laws. In computers, we can stuff laws into it and > create a world -- Alan Kay > > > > __________________________________________________ > > Do You Yahoo!? > > LAUNCH - Your Yahoo! Music Experience > > http://launch.yahoo.com > > -- > 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 Hannes.Tschofenig@mchp.siemens.de Wed May 29 09:54:26 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA03035 for ; Wed, 29 May 2002 09:54:26 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA16276 for ; Wed, 29 May 2002 09:54:25 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g4TDsPh15060; Wed, 29 May 2002 15:54:25 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TDsOF22844; Wed, 29 May 2002 15:54:24 +0200 (MEST) From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: Date: Wed, 29 May 2002 15:59:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020529094532.00ab6b90@localhost> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi > > > At 03:43 PM 5/29/02 +0200, Hannes Tschofenig wrote: > >rsvp travels hop-by-hop (rsvp capable nodes) from one end-point > to an other > >(except if you use some rsvp extensions like rsvp proxy etc.). > hence "RSVP > >is end-to-end in one direction (sender->receiver)" confuses me > somehow. the > >security for rsvp is build on hop-by-hop security based on a > chain-of-trust. > > In the sender->receiver direction, the destination IP address > in the Path message is the receiver's. In the receiver-> > sender direction, the destination IP address in the Resv message > is the address of the PHOP that was picked up by the Path > message. true. the path message is used for path-pinning to allow the resv message to travel the same way back. but this is not related to the question of end-to-end or hop-by-hop protection. both messages travel hop-by-hop. do you think that the hop-by-hop security in rsvp is a good or a bad thing? should there be more than what is currently provided? ciao hannes > > Melinda From Hannes.Tschofenig@mchp.siemens.de Wed May 29 09:54:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA03040 for ; Wed, 29 May 2002 09:54:27 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA16282 for ; Wed, 29 May 2002 09:54:26 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g4TDsP529346; Wed, 29 May 2002 15:54:25 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TDsOF22836; Wed, 29 May 2002 15:54:24 +0200 (MEST) From: "Hannes Tschofenig" To: "Derek Atkins" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Date: Wed, 29 May 2002 15:59:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: [saag] RE: IPsec and RSVP Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi > > "Hannes Tschofenig" writes: > > > hi > > > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > > capable router)? > > You lose the authentication of the end-point requesting the > reservation. rsvp does not provide this property. there is no end-to-end authentication (if i understood you correctly). > If you use ipsec in this way, then each router > knows its peer, but you have no transitive authentication. usually you would like to use the chain-of-trust principal, which means that it is as good as the weakest link. > The only protection you get is protection of on-the-wire > request. true. you protect along an unknown number of non-rsvp capable routers. > You have no protection against a corrupt router > along the path, or indeed no way to know what the actual > original request was. there is no protection against corrupt routers in rsvp. who do you want to know where the original request came from? (the end-point?, networks in between, or all nodes in between?) in rsvp you have no separation of mutable and non-mutable fields and since rsvp router may modify or add something to the message it is difficult (not possible) to use end-to-end security. do you think there is a strong need to provide end-to-end security in rsvp? ciao hannes > > > ciao > > hannes > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From Hannes.Tschofenig@mchp.siemens.de Wed May 29 10:00:22 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id KAA03260 for ; Wed, 29 May 2002 10:00:21 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA18840 for ; Wed, 29 May 2002 10:00:21 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g4TE0Jh17589; Wed, 29 May 2002 16:00:19 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TE0JF26728; Wed, 29 May 2002 16:00:19 +0200 (MEST) From: "Hannes Tschofenig" To: "Derek Atkins" Cc: "Melinda Shore" , "RJ Atkinson" , "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: IPsec and RSVP Date: Wed, 29 May 2002 16:04:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi > > > And we're saying that this chain-of-trust is a bad model, because > anyone close to an edge can inject any amount of bogus data into the > network. you have to differentiate between data traffic and signaling traffic. if you change the chain-of-trust model and require end-to-end nature than this implies that you don't want any router to modify rsvp message (adding something etc.). this is possible by introducing mutable and non-mutable fields and protecting the non-mutable fields end-to-end. the only information you can protect is what qos was requested by one end. since rsvp is not used by its own you could also protect this information at the application layer for example using sip. if nodes in between are unable to verify this information then this would also work. what do you think? > Once it's injected, it's even TRUSTED! yes - if a router is malicious then you have a problem. injecting data traffic by someone else (unauthorized user) is something different. injecting unprotected signaling messages is again something different. > One major problem is > that you lose the origin of the request after the first hop, not to > mention the actual request itself. which nodes need this information and for what? ciao hannes > > -derek > > "Hannes Tschofenig" writes: > > > hi > > > > what do you mean by "in terms of addressing"? > > > > my understanding of rsvp is: > > rsvp travels hop-by-hop (rsvp capable nodes) from one end-point > to an other > > (except if you use some rsvp extensions like rsvp proxy etc.). > hence "RSVP > > is end-to-end in one direction (sender->receiver)" confuses me > somehow. the > > security for rsvp is build on hop-by-hop security based on a > chain-of-trust. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore > > > Sent: Saturday, May 25, 2002 5:18 PM > > > To: RJ Atkinson; Derek Atkins > > > Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec; > > > Security_Area_Advisory_Group > > > Subject: Re: [saag] Re: > > > > > > > > > At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote: > > > >Hmm. I would rather say that RSVP is hop-by-hop and > > > >that (normally) AH/ESP are end-to-end. > > > > > > In terms of addressing, RSVP is end-to-end in one > > > direction (sender->receiver) and hop-by-hop in the > > > other (receiver->sender). > > > > > > >However, if one used (for example) AH with an asymmetric algorithm, > > > >one could perform hop-by-hop authentication of the > > > >packet with AH. This has obvious computational cost > > > >issues so might not be the best choice. > > > > > > The packet payload is going to be modified at each hop, > > > as well, in both directions. > > > > > > Melinda > > > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From Hannes.Tschofenig@mchp.siemens.de Wed May 29 10:18:03 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id KAA03887 for ; Wed, 29 May 2002 10:18:03 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA23713 for ; Wed, 29 May 2002 10:18:02 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g4TEI1h25378; Wed, 29 May 2002 16:18:01 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g4TEI0F08437; Wed, 29 May 2002 16:18:01 +0200 (MEST) From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: Date: Wed, 29 May 2002 16:22:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020529100110.00aad1b0@localhost> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi melinda > > > At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote: > >do you think that the hop-by-hop security in rsvp is a good or a > bad thing? > >should there be more than what is currently provided? > > There needs to be more than what is currently provided, > but, as always, there's a big keying/cert problem, particularly > in a multi-"domain" environment. i fully agree with you. especially in a generic end-to-end case this might be quite difficult. > I don't think the threat > environment is particularly well-understood (I've seen your > NSIS draft but haven't gone through it in detail). i would like to hear your opinion about it. > Clearly > IPSec is not the right answer for Path messages, however, > because while the addressing is end-to-end the payload > contents do change as the packet transits participating > routers. yes. ipsec is definitely not the choice for end-to-end security since it does not allow intermediate nodes to modify the messages. i however have difficulties with the statement that end-to-end security introduced in rsvp solves all problems. (i think that it even introduces more.) my observation is that the interaction between rsvp and other protocols like sip is important especially for accounting and since rsvp is often used together with other protocols. ciao hannes > > Melinda From thomasm@cisco.com Wed May 29 12:02:52 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id MAA06252 for ; Wed, 29 May 2002 12:02:52 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA15170 for ; Wed, 29 May 2002 12:02:51 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4TG2EPI013792; Wed, 29 May 2002 09:02:14 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABT28291; Wed, 29 May 2002 08:59:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA06468; Wed, 29 May 2002 09:02:13 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15604.64389.520614.112373@thomasm-u1.cisco.com> Date: Wed, 29 May 2002 09:02:13 -0700 (PDT) To: Derek Atkins Cc: "Hannes Tschofenig" , "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [saag] Re: IPsec and RSVP Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Derek Atkins writes: > "Hannes Tschofenig" writes: > > > hi > > > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > > capable router)? > > You lose the authentication of the end-point requesting the > reservation. If you use ipsec in this way, then each router > knows its peer, but you have no transitive authentication. > The only protection you get is protection of on-the-wire > request. You have no protection against a corrupt router > along the path, or indeed no way to know what the actual > original request was. Derek, There are two different forms of crypto needed for RSVP: a hop-by-hop integrity object and a policy object. IPsec could in theory replace the integrity object, but cannot replace the policy object. Considering that there is no key distribution for the hop-by-hop integrity objects, IPsec might not be a bad choice in some situations. Mike From thomasm@cisco.com Wed May 29 16:47:23 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id QAA11759 for ; Wed, 29 May 2002 16:47:22 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA22367 for ; Wed, 29 May 2002 16:47:22 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4TKkYuF009482; Wed, 29 May 2002 13:46:34 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABT36387; Wed, 29 May 2002 13:43:48 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA06500; Wed, 29 May 2002 13:46:47 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15605.15926.912770.654169@thomasm-u1.cisco.com> Date: Wed, 29 May 2002 13:46:46 -0700 (PDT) To: "S. Felix Wu" Cc: Hannes Tschofenig , kumar_amara@yahoo.com, dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group In-Reply-To: <3CF50554.4B48FA53@cs.ucdavis.edu> References: <3CF50554.4B48FA53@cs.ucdavis.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [saag] Re: ipsec to secure rsvp Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: S. Felix Wu writes: > Therefore, (according to my old/dusty memory), Fred Baker's proposal > to secure RSVP is based on a key table and key ID to allow the next > hop trusted RSVP router to authenticate (HMAC fashion) the message > without prior seesion-key exchange. Right. There are two competing goals going on with RSVP in this respect: router alert as a discovery mechanism, and security desires which need to know the how to key the next hop integrity object. I don't really see how you reconcile that unless you have group keys on your integrity objects which makes me a little queasy. Mike From wu@cs.ucdavis.edu Wed May 29 12:45:23 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id MAA07144 for ; Wed, 29 May 2002 12:45:23 -0400 (EDT) Received: from soda.cs.ucdavis.edu (soda.cs.ucdavis.edu [169.237.6.187]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA23187 for ; Wed, 29 May 2002 12:45:22 -0400 (EDT) Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.9.3+Sun/8.9.3/CS UCDavis) with ESMTP id JAA13666; Wed, 29 May 2002 09:44:13 -0700 (PDT) Message-ID: <3CF50554.4B48FA53@cs.ucdavis.edu> Date: Wed, 29 May 2002 09:44:04 -0700 From: "S. Felix Wu" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hannes Tschofenig , kumar_amara@yahoo.com, dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [saag] Re: ipsec to secure rsvp Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: The tricky part (my personal opinion) is that, using IPSec, you must know the other endpoint's IP address to establish the SA in the first place. According to my understanding, at least in general, in RSVP, you do NOT know the next hop RSVP router's IP address in path finding messages (I assume that not every Internet router will support RSVP), and sometimes route path might change unpredictably. Therefore, (according to my old/dusty memory), Fred Baker's proposal to secure RSVP is based on a key table and key ID to allow the next hop trusted RSVP router to authenticate (HMAC fashion) the message without prior seesion-key exchange. I have admitted that I haven't followed the thread of progress in RSVP security for a while, so maybe things have been changed. -Felix Hannes Tschofenig wrote: > > hi > > there is no reason why not to use ipsec to secure rsvp. especially in the > core network (between routers) this might be a reasonable approach. using > ipsec to secure the traffic between the application (end-host) and the first > hop router is however more difficult. > > ciao > hannes > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara > > Sent: Friday, May 24, 2002 4:37 PM > > To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > > Subject: Re: > > > > > > Why don't you use IPSEC to secure RSVP. > > > > Satish Amara > > --- Dong wrote: > > > Roy, > > > > > > I just read a paper "Preventing Denial of Service > > > Attacks on Quality of Service", which is written by > > > some guys from N.C. State university and UC Davis. > > > The service quality to legimative users could be > > > degraded by attacks on control flow or data flow. > > > For example, an illegal user can forge a reservation > > > message, so he can receive an unauthorized amount of > > > resources. I just wanna to know what threats exist > > > in providing QoS, and what the state-of-art > > > techniques to prevent, detect and counter those > > > attacks, and of course recovery mothods as well. > > > > > > Thx a lot. > > > > > > Dong > > > > > > > > > Dong, > > > Please be a little more precise in what you are > > > asking for, i.e. > > > > > > 3-5 bullet list items on what kind of security you > > > seek. > > > > > > Roy > > > > > > -----Original Message----- > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > Sent: Thursday, May 23, 2002 2:05 PM > > > To: Security_Area_Advisory_Group; IPsec > > > Subject: Secure QoS > > > > > > > > > Hi, > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > on that? Thx. > > > > > > Dong > > > > > > > > _____________________________________________________________ > > > Get Tsinghua University free email account: > > > www.tsinghua.com > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > _____________________________________________________________ > > > Get Tsinghua University free email account: > > > www.tsinghua.com > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > _____________________________________________________________ > > > Promote your group and strengthen ties to your > > > members with email@yourgroup.org by Everyone.net > > http://www.everyone.net/?btn=tag > > > > > > ===== > > In natural science, Nature has given us a world and we're just to > > discover its laws. In computers, we can stuff laws into it and > > create a world -- Alan Kay > > > > __________________________________________________ > > Do You Yahoo!? > > LAUNCH - Your Yahoo! Music Experience > > http://launch.yahoo.com -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From wu@cs.ucdavis.edu Wed May 29 13:03:41 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id NAA07572 for ; Wed, 29 May 2002 13:03:40 -0400 (EDT) Received: from soda.cs.ucdavis.edu (soda.cs.ucdavis.edu [169.237.6.187]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA00090; Wed, 29 May 2002 13:03:40 -0400 (EDT) Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.9.3+Sun/8.9.3/CS UCDavis) with ESMTP id KAA13734; Wed, 29 May 2002 10:03:27 -0700 (PDT) Message-ID: <3CF509D5.C0530394@cs.ucdavis.edu> Date: Wed, 29 May 2002 10:03:18 -0700 From: "S. Felix Wu" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hannes Tschofenig CC: Derek Atkins , SatishK Amara , dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [saag] Re: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: It depends on what are the security requirements and threats. In my opinion, RSVP security is really neither hop-by-hop nor end-to-end (or I should say it is a mixture of both). Certain fields in RSVP are "mutable" (for example, maximum available bandwidth along the route path), and therefore, a pure end-to-end will not be possible. On the other hand, if we assume (i.e., our threat model) that an intermediate RSVP router (on the route path) can be malicious, then you need some forms of end-to-end to protect at least those "static" fields in an end-to-end fashion. My students and I studied this problem a few years ago and the following is a web link to our paper: http://arqos.csc.ncsu.edu/papers/1999_10_iwqos99.pdf This work is somewhat old, but hopefully it will provide some information about the technical difficulties in dealing with RSVP security. -Felix Hannes Tschofenig wrote: > > hi > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > capable router)? > > ciao > hannes > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins > > Sent: Saturday, May 25, 2002 5:01 AM > > To: SatishK Amara > > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > > Subject: Re: > > > > > > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > > > -derek > > > > SatishK Amara writes: > > > > > Why don't you use IPSEC to secure RSVP. > > > > > > Satish Amara > > > --- Dong wrote: > > > > Roy, > > > > > > > > I just read a paper "Preventing Denial of Service > > > > Attacks on Quality of Service", which is written by > > > > some guys from N.C. State university and UC Davis. > > > > The service quality to legimative users could be > > > > degraded by attacks on control flow or data flow. > > > > For example, an illegal user can forge a reservation > > > > message, so he can receive an unauthorized amount of > > > > resources. I just wanna to know what threats exist > > > > in providing QoS, and what the state-of-art > > > > techniques to prevent, detect and counter those > > > > attacks, and of course recovery mothods as well. > > > > > > > > Thx a lot. > > > > > > > > Dong > > > > > > > > > > > > Dong, > > > > Please be a little more precise in what you are > > > > asking for, i.e. > > > > > > > > 3-5 bullet list items on what kind of security you > > > > seek. > > > > > > > > Roy > > > > > > > > -----Original Message----- > > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > > Sent: Thursday, May 23, 2002 2:05 PM > > > > To: Security_Area_Advisory_Group; IPsec > > > > Subject: Secure QoS > > > > > > > > > > > > Hi, > > > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > > on that? Thx. > > > > > > > > Dong > > > > > > > > > > > _____________________________________________________________ > > > > Get Tsinghua University free email account: > > > > www.tsinghua.com > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > > > > > > _____________________________________________________________ > > > > Get Tsinghua University free email account: > > > > www.tsinghua.com > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > _____________________________________________________________ > > > > Promote your group and strengthen ties to your > > > > members with email@yourgroup.org by Everyone.net > > > http://www.everyone.net/?btn=tag > > > > > > > > > ===== > > > In natural science, Nature has given us a world and we're just > > to discover its laws. In computers, we can stuff laws into it and > > create a world -- Alan Kay > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > LAUNCH - Your Yahoo! Music Experience > > > http://launch.yahoo.com > > > > -- > > 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 -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From alaadas@kaau.edu.sa Wed May 29 17:46:27 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id RAA12870 for ; Wed, 29 May 2002 17:46:26 -0400 (EDT) Received: from relay2.kaau.edu.sa ([212.26.82.17]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01503 for ; Wed, 29 May 2002 17:46:22 -0400 (EDT) Received: from kaau.edu.sa (mailhub.kaau.edu.sa [212.26.83.7]) by relay2.kaau.edu.sa (8.11.0/8.11.0) with ESMTP id g4TLGps27780; Thu, 30 May 2002 00:16:51 +0300 Received: from amanda2 ([212.26.85.206]) by kaau.edu.sa (8.9.3+Sun/8.9.3) with SMTP id SAA13461; Wed, 29 May 2002 18:52:04 -0300 (GMT) Message-ID: <001501c2075a$0d1f4780$6540fea9@amanda2> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Hannes Tschofenig" , "Melinda Shore" Cc: "IPsec" , "Security_Area_Advisory_Group" References: <5.1.0.14.0.20020529094532.00ab6b90@localhost> <5.1.0.14.0.20020529100110.00aad1b0@localhost> Subject: Re: [saag] Re: Date: Thu, 30 May 2002 00:44:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hi The best approach in my view is to use CORBA and CORBsec to deal with path messages, I believe if CORBA routers can be realized very soon, most of your IPsec shortcomings will be resolved. Ahmed ----- Original Message ----- From: "Melinda Shore" To: "Hannes Tschofenig" Cc: "IPsec" ; "Security_Area_Advisory_Group" Sent: Wednesday, May 29, 2002 5:06 PM Subject: RE: [saag] Re: > At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote: > >do you think that the hop-by-hop security in rsvp is a good or a bad thing? > >should there be more than what is currently provided? > > There needs to be more than what is currently provided, > but, as always, there's a big keying/cert problem, particularly > in a multi-"domain" environment. I don't think the threat > environment is particularly well-understood (I've seen your > NSIS draft but haven't gone through it in detail). Clearly > IPSec is not the right answer for Path messages, however, > because while the addressing is end-to-end the payload > contents do change as the packet transits participating > routers. > > Melinda > From dboney@gwu.edu Thu May 30 15:08:59 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id PAA03885 for ; Thu, 30 May 2002 15:08:59 -0400 (EDT) Received: from hermes.toad.net (hermes.toad.net [162.33.130.251]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA29993 for ; Thu, 30 May 2002 15:08:58 -0400 (EDT) Received: from gwu.edu (dboney-01.dslbr.toad.net [162.33.159.86]) by hermes.toad.net (8.11.6/8.11.6) with ESMTP id g4UJ8x326815 for ; Thu, 30 May 2002 15:08:59 -0400 Message-ID: <3CF678C9.2020009@gwu.edu> Date: Thu, 30 May 2002 15:08:57 -0400 From: "David G. Boney" Organization: The George Washington University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] MPLS Security Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hi, Is there any work being done on MPLS security issues? -- Sincerely, David G. Boney Graduate Research Assistant Department of Electrical and Computer Engineering The George Washington University Phillips Hall, Suite 607 801 22nd Street, N.W. Washington, DC 20052 http://student.seas.gwu.edu/~dboney mailto:dboney@gwu.edu Department Phone (202) 994-6083 Department Fax (202) 994-0227 "I don't get up until noon, I only work a couple of hours a day, and I spend the rest of my time reading. I guess my calling in life is to be a professor." From Hannes.Tschofenig@mchp.siemens.de Fri May 31 02:44:41 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id CAA14727 for ; Fri, 31 May 2002 02:44:41 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA15529 for ; Fri, 31 May 2002 02:44:40 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g4V6ido10705; Fri, 31 May 2002 08:44:39 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id g4V6icW04956; Fri, 31 May 2002 08:44:38 +0200 (MEST) From: "Hannes Tschofenig" To: "S. Felix Wu" , , , "IPsec" , "Security_Area_Advisory_Group" Date: Fri, 31 May 2002 08:49:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CF50554.4B48FA53@cs.ucdavis.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [saag] RE: ipsec to secure rsvp Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi felix! > -----Original Message----- > From: S. Felix Wu [mailto:wu@cs.ucdavis.edu] > Sent: Wednesday, May 29, 2002 6:44 PM > To: Hannes Tschofenig; kumar_amara@yahoo.com; dong_wei@tsinghua.com; > IPsec; Security_Area_Advisory_Group > Subject: Re: ipsec to secure rsvp > > > > The tricky part (my personal opinion) is that, using IPSec, you > must know the other endpoint's IP address to establish the SA in > the first place. According to my understanding, at least in general, > in RSVP, you do NOT know the next hop RSVP router's IP address in > path finding messages (I assume that not every Internet router will > support RSVP), and sometimes route path might change unpredictably. true - rsvp does not describe how to learn the identity of the next rsvp aware next hop (i think it the documents say something like 'by other means...'). this information needs to be available otherwise the integrity object cannot be added. > > Therefore, (according to my old/dusty memory), Fred Baker's proposal > to secure RSVP is based on a key table and key ID to allow the next > hop trusted RSVP router to authenticate (HMAC fashion) the message > without prior seesion-key exchange. that is not going to work. maybe he said something more. > > I have admitted that I haven't followed the thread of progress in > RSVP security for a while, so maybe things have been changed. there has not been a discussion as far as i remember. ciao hannes > > -Felix > > > > Hannes Tschofenig wrote: > > > > hi > > > > there is no reason why not to use ipsec to secure rsvp. > especially in the > > core network (between routers) this might be a reasonable > approach. using > > ipsec to secure the traffic between the application (end-host) > and the first > > hop router is however more difficult. > > > > ciao > > hannes > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara > > > Sent: Friday, May 24, 2002 4:37 PM > > > To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > > > Subject: Re: > > > > > > > > > Why don't you use IPSEC to secure RSVP. > > > > > > Satish Amara > > > --- Dong wrote: > > > > Roy, > > > > > > > > I just read a paper "Preventing Denial of Service > > > > Attacks on Quality of Service", which is written by > > > > some guys from N.C. State university and UC Davis. > > > > The service quality to legimative users could be > > > > degraded by attacks on control flow or data flow. > > > > For example, an illegal user can forge a reservation > > > > message, so he can receive an unauthorized amount of > > > > resources. I just wanna to know what threats exist > > > > in providing QoS, and what the state-of-art > > > > techniques to prevent, detect and counter those > > > > attacks, and of course recovery mothods as well. > > > > > > > > Thx a lot. > > > > > > > > Dong > > > > > > > > > > > > Dong, > > > > Please be a little more precise in what you are > > > > asking for, i.e. > > > > > > > > 3-5 bullet list items on what kind of security you > > > > seek. > > > > > > > > Roy > > > > > > > > -----Original Message----- > > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > > Sent: Thursday, May 23, 2002 2:05 PM > > > > To: Security_Area_Advisory_Group; IPsec > > > > Subject: Secure QoS > > > > > > > > > > > > Hi, > > > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > > on that? Thx. > > > > > > > > Dong > > > > > > > > > > > _____________________________________________________________ > > > > Get Tsinghua University free email account: > > > > www.tsinghua.com > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > > > > > > _____________________________________________________________ > > > > Get Tsinghua University free email account: > > > > www.tsinghua.com > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > _____________________________________________________________ > > > > Promote your group and strengthen ties to your > > > > members with email@yourgroup.org by Everyone.net > > > http://www.everyone.net/?btn=tag > > > > > > > > > ===== > > > In natural science, Nature has given us a world and we're just to > > > discover its laws. In computers, we can stuff laws into it and > > > create a world -- Alan Kay > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > LAUNCH - Your Yahoo! Music Experience > > > http://launch.yahoo.com > > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- From Hannes.Tschofenig@mchp.siemens.de Fri May 31 02:44:42 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id CAA14732 for ; Fri, 31 May 2002 02:44:41 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA01810 for ; Fri, 31 May 2002 02:44:41 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g4V6icG07849; Fri, 31 May 2002 08:44:38 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id g4V6ibW04935; Fri, 31 May 2002 08:44:37 +0200 (MEST) From: "Hannes Tschofenig" To: "Michael Thomas" , "S. Felix Wu" Cc: , , "IPsec" , "Security_Area_Advisory_Group" Date: Fri, 31 May 2002 08:49:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15605.15926.912770.654169@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [saag] RE: ipsec to secure rsvp Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi mike! > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, May 29, 2002 10:47 PM > To: S. Felix Wu > Cc: Hannes Tschofenig; kumar_amara@yahoo.com; dong_wei@tsinghua.com; > IPsec; Security_Area_Advisory_Group > Subject: Re: ipsec to secure rsvp > > > S. Felix Wu writes: > > Therefore, (according to my old/dusty memory), Fred Baker's proposal > > to secure RSVP is based on a key table and key ID to allow the next > > hop trusted RSVP router to authenticate (HMAC fashion) the message > > without prior seesion-key exchange. > > Right. There are two competing goals going on with > RSVP in this respect: router alert as a discovery > mechanism, and security desires which need to know > the how to key the next hop integrity object. I > don't really see how you reconcile that unless you > have group keys on your integrity objects which > makes me a little queasy. i fully agree with you. if you want to use protection based on symmetric cryptography then you first must learn the identity of the node to whom you want to authenticate to. (and the keys need to be in place). with public key cryptography things are somewhat different. but from a pratical perspective it does not provide the necessary performance. i guess you can agree with me on this issue. > > Mike ciao hannes From Hannes.Tschofenig@mchp.siemens.de Fri May 31 02:44:45 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id CAA14737 for ; Fri, 31 May 2002 02:44:44 -0400 (EDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA01820 for ; Fri, 31 May 2002 02:44:44 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g4V6idG07856; Fri, 31 May 2002 08:44:39 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id g4V6idW04964; Fri, 31 May 2002 08:44:39 +0200 (MEST) From: "Hannes Tschofenig" To: "Michael Thomas" , "Derek Atkins" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Date: Fri, 31 May 2002 08:49:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15604.64389.520614.112373@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [saag] RE: IPsec and RSVP Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi derek! > Derek, > > There are two different forms of crypto needed for > RSVP: a hop-by-hop integrity object and a policy > object. true. the policy object can additionally contain a integrity object (together with the other credentials there). > IPsec could in theory replace the > integrity object, but cannot replace the policy > object. Considering that there is no key > distribution for the hop-by-hop integrity objects, > IPsec might not be a bad choice in some > situations. > > Mike From Hannes.Tschofenig@mchp.siemens.de Fri May 31 02:46:12 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id CAA14813 for ; Fri, 31 May 2002 02:46:11 -0400 (EDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA01809; Fri, 31 May 2002 02:44:40 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g4V6ico10701; Fri, 31 May 2002 08:44:39 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id g4V6icW04947; Fri, 31 May 2002 08:44:38 +0200 (MEST) From: "Hannes Tschofenig" To: "S. Felix Wu" Cc: "Derek Atkins" , "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Date: Fri, 31 May 2002 08:49:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CF509D5.C0530394@cs.ucdavis.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [saag] RE: Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi felix! > > > It depends on what are the security requirements and threats. yes, this is always true. when looking at the threats for a qos signling protocol it had two problems: a) why do you really need end-to-end security if the protocol operates in a hop-by-hop manner. i understand if someone mentiones the accounting issues (who pays for what). but it is strange to introduce them all into a qos signaling protocol since there are other protocols that have to executed first in a typical application (i.e. rsvp or other qos signaling protocols will not be send between the two endpoints without running other protocols too - if used for end-to-end qos signaling). b) the threat about a malicous qos (rsvp) aware node. if an adversary manages to hack into a aaa, sip, etc. network element then he is obviously able to do many actions. why should this be different for rsvp (or other qos signaling protocols)? if an adversary is able to hack into the pdp, into an edge router, etc. then he is able to mount all types of attacks. who should this be prevented? the only difference between rsvp and for example aaa or sip is the possibly large number of nodes involved in the qos signaling. there is however an architectural question whether this is really necessary/practical since there are extensions that suggest that only the access network should store per-flow information (i.e. run rsvp) and the core networks have aggregated flows (trunks) for example based on diffserv. hence in practice the number of nodes is not as large as it might look at the first sight. additionally there is a strong desire to keep the latency (and bandwidth consumption with signaling) low. > In my opinion, RSVP security is really neither hop-by-hop nor > end-to-end (or I should say it is a mixture of both). it is definitely not end-to-end. with hop-by-hop you are right since there are two integrity objects: one within the rsvp message part of the message and the other one in the policy object. additionally there are credentials in the policy object. furtheremore there are policy aware and policy unaware nodes. > > Certain fields in RSVP are "mutable" (for example, maximum > available bandwidth along the route path), and therefore, a > pure end-to-end will not be possible. On the other hand, if > we assume (i.e., our threat model) that an intermediate RSVP > router (on the route path) can be malicious, then you need > some forms of end-to-end to protect at least those "static" > fields in an end-to-end fashion. i agree with you. rsvp has mutable and non-mutable fields but they are not labled as such (or there is no separation between mutable and non-mutalbe fields). hence it is difficult to simply protect them by adding an other "end-to-end integrity-object". additionally with this approach you obviously introduce key management protocols which might be not too easy to solve (establishing security associations between two arbitrary nodes turned out to be difficult lacking a global pki, or aaa/kerberos, etc. infrastructure. if some other protocols are executed before rsvp starts ( these protocols have already allowed to figure out who will pay for what) then these credentials (i call it opaque token) only need to be included into rsvp without a need to add end-to-end security issues into rsvp itself and allow other protocols to do that (e.g. sip). there is obviously a need to have a interaction with other protocols including diameter (aaa in general) since accounting records need to be produced and transmitted to the appropriate locations. > > My students and I studied this problem a few years ago and the > following is a web link to our paper: > > http://arqos.csc.ncsu.edu/papers/1999_10_iwqos99.pdf > > This work is somewhat old, but hopefully it will provide some > information about the technical difficulties in dealing with > RSVP security. thanks. i read it some time ago. i do not remember it exactly but i think you did not propose to use end-to-end security - it was more like a network to network hop security using digital signatures. ciao hannes > -Felix > > > Hannes Tschofenig wrote: > > > > hi > > > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > > capable router)? > > > > ciao > > hannes > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins > > > Sent: Saturday, May 25, 2002 5:01 AM > > > To: SatishK Amara > > > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > > > Subject: Re: > > > > > > > > > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > > > > > -derek > > > > > > SatishK Amara writes: > > > > > > > Why don't you use IPSEC to secure RSVP. > > > > > > > > Satish Amara > > > > --- Dong wrote: > > > > > Roy, > > > > > > > > > > I just read a paper "Preventing Denial of Service > > > > > Attacks on Quality of Service", which is written by > > > > > some guys from N.C. State university and UC Davis. > > > > > The service quality to legimative users could be > > > > > degraded by attacks on control flow or data flow. > > > > > For example, an illegal user can forge a reservation > > > > > message, so he can receive an unauthorized amount of > > > > > resources. I just wanna to know what threats exist > > > > > in providing QoS, and what the state-of-art > > > > > techniques to prevent, detect and counter those > > > > > attacks, and of course recovery mothods as well. > > > > > > > > > > Thx a lot. > > > > > > > > > > Dong > > > > > > > > > > > > > > > Dong, > > > > > Please be a little more precise in what you are > > > > > asking for, i.e. > > > > > > > > > > 3-5 bullet list items on what kind of security you > > > > > seek. > > > > > > > > > > Roy > > > > > > > > > > -----Original Message----- > > > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > > > Sent: Thursday, May 23, 2002 2:05 PM > > > > > To: Security_Area_Advisory_Group; IPsec > > > > > Subject: Secure QoS > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > > > on that? Thx. > > > > > > > > > > Dong > > > > > > > > > > > > > > _____________________________________________________________ > > > > > Get Tsinghua University free email account: > > > > > www.tsinghua.com > > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________ > > > > > Get Tsinghua University free email account: > > > > > www.tsinghua.com > > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > _____________________________________________________________ > > > > > Promote your group and strengthen ties to your > > > > > members with email@yourgroup.org by Everyone.net > > > > http://www.everyone.net/?btn=tag > > > > > > > > > > > > ===== > > > > In natural science, Nature has given us a world and we're just > > > to discover its laws. In computers, we can stuff laws into it and > > > create a world -- Alan Kay > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > LAUNCH - Your Yahoo! Music Experience > > > > http://launch.yahoo.com > > > > > > -- > > > 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 > > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- From Hannes.Tschofenig@mchp.siemens.de Fri May 31 02:52:12 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id CAA15022 for ; Fri, 31 May 2002 02:52:11 -0400 (EDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA02770 for ; Fri, 31 May 2002 02:52:11 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g4V6ibs11555; Fri, 31 May 2002 08:44:37 +0200 (MEST) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id g4V6iXW04897; Fri, 31 May 2002 08:44:33 +0200 (MEST) From: "Hannes Tschofenig" To: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" , "Michael Thomas" , "Derek Atkins" Date: Fri, 31 May 2002 08:49:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [saag] end-to-end security and proxy rsvp Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: hi from the previous mails i read that some of you would like to see end-to-end security in a qos signaling protocol. i don't know how many of you have read the draft about proxy rsvp where a node along the path simply acts on behalf of an end-node. if using end-to-end security within rsvp then the proxy rsvp case is quite difficult in the sense that the other end-host (although possibly not rsvp capable) has to transmit credentials to (an possibly unknown) rsvp proxy to let him act on his behalf. what do you think? is there a security problem with the proxy rsvp approach? see draft: draft-ietf-rsvp-proxy-03.txt (there might also be similar issues related to the draft localized rsvp draft-manner-lrsvp-00.txt which also uses proxy ideas). ciao hannes From raif@fl.net.au Thu Jun 20 14:16:00 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id OAA05018 for ; Thu, 20 Jun 2002 14:15:58 -0400 (EDT) Received: from delenn.fl.net.au (int-mail.syd.fl.net.au [202.181.0.28]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19261 for ; Thu, 20 Jun 2002 14:15:57 -0400 (EDT) Received: from fl.net.au (a5-p52.syd.fl.net.au [202.181.2.52]) by delenn.fl.net.au (Postfix) with ESMTP id 0C1D717FE0D; Fri, 21 Jun 2002 04:20:31 +1000 (EST) Message-ID: <3D121BEC.1030503@fl.net.au> Date: Fri, 21 Jun 2002 04:16:12 +1000 From: "Raif S. Naffah" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu, SASL list Cc: Keith Burdis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Algorithm Naming Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Earlier, this year i sent an email about the above subject. The following draft is an attempt to address this issue. Title : Algorithm naming Author(s) : R. Naffah, K. Burdis Filename : draft-naffah-naming-00.txt Pages : 27 Date : 19-Jun-02 Albeit incomplete, this document describes a process for registering cryptographic algorithm names and parameters to ease referencing of such information from IETF Drafts and RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-naffah-naming-00.txt cheers; rsn From owner-saag@MIT.EDU Fri Jul 5 07:59:03 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id HAA26989 for ; Fri, 5 Jul 2002 07:59:03 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id HAA01410 for ; Fri, 5 Jul 2002 07:59:03 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id HAA20268 Fri, 5 Jul 2002 07:45:04 -0400 (EDT) Received: by sentry.gw.tislabs.com; id HAA19241; Fri, 5 Jul 2002 07:58:22 -0400 (EDT) Received: from odin.ietf.org(132.151.1.176) by sentry.gw.tislabs.com via smap (V5.5) id xma019226; Fri, 5 Jul 02 07:57:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20360; Fri, 5 Jul 2002 07:57:24 -0400 (EDT) Message-Id: <200207051157.HAA20360@ietf.org> To: IETF-Announce:;;;;@tislabs.com;;; Cc: RFC Editor Cc: Internet Architecture Board Cc: saag@lists.tislabs.com From: The IESG Date: Fri, 05 Jul 2002 07:57:24 -0400 Subject: [saag] Protocol Action: Strong Security Requirements for IETF Standard Protocols to BCP Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: The IESG has approved the Internet-Draft "Strong Security Requirements for IETF Standard Protocols" as a Best Current Practice. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Steve Bellovin. Technical Summary This memo gives the rationale and requirements for use of encryption and other cryptographic technology when designing Internet protocols. Working Group Summary This document has been reviewed by the SAAG working group. Protocol Quality Steve Bellovin reviewed this document for the IESG. Note to RFC Editor: Please change the title to "Strong Security Requirements for IETF Standard Protocols" From owner-saag@MIT.EDU Wed Jul 17 20:34:55 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id UAA17958 for ; Wed, 17 Jul 2002 20:34:54 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA17784 for ; Wed, 17 Jul 2002 20:34:54 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id UAA23386; Wed, 17 Jul 2002 20:18:53 -0400 (EDT) Received: by sentry.gw.tislabs.com; id UAA04057; Wed, 17 Jul 2002 20:32:30 -0400 (EDT) Received: from unknown(208.10.194.50) by sentry.gw.tislabs.com via smap (V5.5) id xma004039; Thu, 18 Jul 02 00:31:32 GMT Received: by SJCXCH01.hifn.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 17:35:40 -0700 Message-ID: From: Russell Dietz To: IPSec Working Group , SAAG Date: Wed, 17 Jul 2002 17:35:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: To the IPSec Working Group and Security Area Directors: The purpose of this letter is to comment on an existing Internet Draft, draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, co-authored by S. Frankel and S. Kelley. This draft, hereafter referred to as DRAFT-SHA-256 for brevity, defines how to use the new SHA-256 algorithm from NIST (FIPS 180-2) for packet authentication within the ESP and AH mechanisms of IPSec. Our basic argument here is that, while the new SHA-256 algorithm is definitely useful in other contexts, in fact there is no evidence that DRAFT-SHA-256 provides any meaningful additional cryptographic security over the HMAC-SHA-1-96 algorithm defined in RFC2406 and already in widespread use for packet authentication in IPSec. For all we know, quite the contrary may be true, as SHA-256 is a new transform and thus has seen considerably less public review so far than SHA1 has already received. In any case, it is extremely unlikely that HMAC-SHA1 will be the weak point in any system using IPSec. Hence, it is not clear that trying to improve its security makes any sense, given the costs and instability associated with such a change. Unfortunately, the current draft is misleading in this regard: "Using the SHA-256 block cipher, with its increased block size (512 bits) and increased hash length (256 bits), provides the new algorithm with the ability to withstand continuing advances in crypto-analytic techniques and computational capability. It also allows less frequent re-keying, which is useful for high-speed networks and high-volume applications." It is our belief that, as currently defined in DRAFT-SHA-256, the use of SHA-256 does not achieve any of these stated goals. First of all, the block size of SHA-256 (512 bits) is identical to that of SHA-1, so the first assertion in the quote above is simply false, although frankly it would have no relevance if true. Second, there is no known reason why DRAFT-SHA-256 would in fact allow less frequent rekeying, using either 32-bit or 64-bit sequence numbers. Finally, and most importantly, while it is true that SHA-256 can output 256 bits, in the current draft the HMAC-SHA-256 output is in fact truncated to 96 bits, as is HMAC-SHA-1 in RFC2406. For the HMAC-SHA-1-96 and DRAFT-SHA-256 algorithms, there is every reason to believe that the limiting factor in security is the number of bits of hash included in the packet, not the length before truncation. The best attacks known on HMAC-SHA-1-96 and DRAFT-SHA-256 depend only on the length after truncation, not the length before truncation. Hence, the HMAC-SHA-1-96 and DRAFT-SHA-256 have equivalent security against known attacks, and there seems to be little reason to prefer either one over the other, from a cryptographic perspective. For any given number of output bits, up to the SHA-1 limit of 160 bits, this would continue to be the case. If it was desired to have a MAC value longer than 160 bits, then the use of SHA-256 would likely be appropriate, but there is no apparent need for such a MAC tag length, according to current knowledge. It is possible that the draft was initiated from a fundamental misunderstanding of Figure 1 (page 3) of the NIST draft FIPS 180-2. This figure states that the "security" of SHA-1 is 80 bits, while the "security" of SHA-256 is 128 bits. A naive reading of this figure would thus lead one to conclude that only SHA-256 is appropriate for use with AES-128. However, the figure in question deals with the strength of the hash functions against collisions as part of a digital signature scheme. It is likely that the use of SHA-256 is very appropriate for the digital signatures used in the certificates of the IKE exchange used to generate AES-128 and HMAC-SHA-1-96 keys for ESP and AH. This is in fact the application for which SHA-256 was designed. However, while Figure 1 in FIPS 180-2 is correct for digital signatures, it has no direct relevance to the issue of packet authentication in ESP and AH as addressed in DRAFT-SHA-256. Packet authentication has a completely different attack model. In particular, there is no known feasible "birthday attack" problem in the packet authentication context, as has been shown by Krawczyk and others (e.g., "Keying Hash Functions for Message Authentication" by Bellare, Canetti, and Krawczyk, Crypto '96). Since HMAC-SHA1-96 (RFC2406) is already a "MUST" for IPSec compliance, all IPSec implementations, hardware or software, already have it and must continue to support it for many years to come. Any possible argument that somehow SHA-256 can replace SHA-1 to save hardware cost is thus extremely ill-founded. In fact, quite the opposite is true: adding DRAFT-SHA-256 as an IPSec option will only increase hardware cost, with no accompanying security benefit. We expect that if the WG approved DRAFT-SHA-256, it would be optional rather than mandatory. However, there would be a strong risk that vendors and their customers might feel compelled to use it out of a misunderstanding of the cryptographic issues. Already we have heard potential customers asking for support for DRAFT-SHA-256, with the rationale being, "if IETF approves it, it must be good". Our purpose in submitting this letter is to make sure that the IPSec working group has a reasonable understanding of the issues involved in DRAFT-SHA-256. If the WG decides to approve the draft, we strongly suggest that, at a bare minimum, a) the inaccurate claims discussed above should be corrected or removed, b) the document should be re-worked to clarify the fact that SHA1 is perfectly adequate, according to current knowledge, c) the resulting transform should be qualified as optional-to-implement, not mandatory, and d) the draft should make clear under what circumstances the transform is an option worth pursuing (e.g. if SHA-1 is broken by advances in cryptanalysis, but SHA-256 is not) However, given that there is no known cryptographic benefit to implementing this proposed standard, we respectfully submit that the IPSec WG should not approve this draft. Doug Whiting, dwhiting@hifn.com, Hifn David McGrew, mcgrew@cisco.com, Cisco Dave Wagner, daw@cs.berkeley.edu, UC Berkeley Russ Housely, rhousley@rsdsecurity.com, RSA Labs Niels Ferguson, niels@ferguson.net, MacFergus BV Thomas Hardjono, thomas.hardjono@verisign.com, Verisign Scott Fluhrer, fluhrer@cisco.com, Cisco Jesse Walker, jesse.walker@intel.com, Intel Mike Sabin, mike.sadin@worldnet.att.net, Independent Consultant John Kelsey, kelsey.j@ix.netcom.com, Certicom Russell Dietz, rdietz@hifn.com, Hifn Russell Dietz Hifn, Inc. pgp-fingerprint: CEE3 58B0 DD09 4EA5 7266 BF1E B5F6 4D1A 4AD1 65B4 From owner-saag@MIT.EDU Wed Jul 17 22:12:47 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id WAA19397 for ; Wed, 17 Jul 2002 22:12:46 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA05149 for ; Wed, 17 Jul 2002 22:12:46 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id VAA23652; Wed, 17 Jul 2002 21:56:20 -0400 (EDT) Received: by sentry.gw.tislabs.com; id WAA06011; Wed, 17 Jul 2002 22:09:57 -0400 (EDT) Received: from auemail1.lucent.com(192.11.223.161) by sentry.gw.tislabs.com via smap (V5.5) id xma005998; Thu, 18 Jul 02 02:09:04 GMT Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6I29aU02371; Wed, 17 Jul 2002 22:09:37 -0400 (EDT) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id WAA13895; Wed, 17 Jul 2002 22:09:30 -0400 (EDT) Cc: IPSec Working Group , SAAG Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id WAA13880; Wed, 17 Jul 2002 22:09:26 -0400 (EDT) Message-ID: <3D36232E.93F7FB5F@lucent.com> Date: Wed, 17 Jul 2002 22:08:46 -0400 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Russell Dietz Original-CC: IPSec Working Group , SAAG Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Russell Dietz wrote: > Unfortunately, the current draft is misleading in this regard: > "Using the SHA-256 block cipher, with its increased block size (512 bits) > and increased hash length (256 bits), provides the new algorithm with the > ability to withstand continuing advances in crypto-analytic techniques and > computational capability............." > It is our belief that, as currently defined in DRAFT-SHA-256, the use of > SHA-256 does not achieve any of these stated goals. > > First of all, the block size of SHA-256 (512 bits) is identical to that of > SHA-1, so the first assertion in the quote above is simply false, although > frankly it would have no relevance if true. Second, there is no known > reason why DRAFT-SHA-256 would in fact allow less frequent rekeying, using > either 32-bit or 64-bit sequence numbers. Actually it's even worse than that. Yes, SHA-256 outputs twice as many bits as SHA-1. Sure, but who says those bits are RANDOM? Uncorrelated? The SHA family of functions is a Hash family, not PRF. Thus, longer output for re-keying purposes means exactly nothing. [It does make a difference for hash/MAC of course, but not rekeying.] [If I may toot my own horn here - please look at the PRF-from-MAC construct, that comes with formal security proofs, submitted by yours truly :-). It talks about hard random bits suitable for keying material.] Thanks! -- Regards, Uri -=-=-=<>=-=- From owner-saag@MIT.EDU Thu Jul 18 00:46:59 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id AAA21628 for ; Thu, 18 Jul 2002 00:46:59 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA06621 for ; Thu, 18 Jul 2002 00:46:59 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id AAA23968; Thu, 18 Jul 2002 00:32:42 -0400 (EDT) Received: by sentry.gw.tislabs.com; id AAA08714; Thu, 18 Jul 2002 00:46:20 -0400 (EDT) Received: from gnat.inet.org(63.108.254.91) by sentry.gw.tislabs.com via smap (V5.5) id xma008710; Thu, 18 Jul 02 04:45:49 GMT Received: from mosquito.inet.org (T23-TNOZAKI.extremenetworks.com [10.4.2.119]) by gnat.inet.org (Postfix) with ESMTP id 716FE67103; Wed, 17 Jul 2002 20:53:48 -0400 (EDT) Date: Thu, 18 Jul 2002 00:41:35 -0400 Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG Message-Id: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors From: RJ Atkinson Content-Transfer-Encoding: 7bit To: Russell Dietz X-Mailer: Apple Mail (2.482) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Wednesday, July 17, 2002, at 08:35 PM, Russell Dietz wrote: > To the IPSec Working Group and Security Area Directors: > > The purpose of this letter is to comment on an existing Internet Draft, > draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, co-authored by S. > Frankel and S. Kelley. This draft, hereafter referred to as > DRAFT-SHA-256 > for brevity, defines how to use the new SHA-256 algorithm from NIST > (FIPS > 180-2) for packet authentication within the ESP and AH mechanisms of > IPSec. Russell, I'm pretty indifferent to the topic of what ought or ought not be mandatory-to-implement or maybe even standards-track RFC versus informational RFC. I am remarkably indifferent to any of the mathematical parts of your note or Uri's followup. I do feel pretty strongly that the above referenced draft ought to be permitted to be published, at least as an Informational RFC, so that those folks who choose to implement/deploy it can do so in an interoperable manner. Trying to prevent people from publishing open specifications for entirely optional-to-implement technology is NOT consistent with the Internet tradition. I would hope that the RFC Editor would apply their own good judgement to an individual request to publish such a document as an Informational RFC if the situation should arise. Yours, Ran rja@extremenetworks.com From owner-saag@MIT.EDU Thu Jul 18 01:38:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id BAA22414 for ; Thu, 18 Jul 2002 01:38:26 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA11222 for ; Thu, 18 Jul 2002 01:38:26 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id BAA24029; Thu, 18 Jul 2002 01:22:49 -0400 (EDT) Received: by sentry.gw.tislabs.com; id BAA09286; Thu, 18 Jul 2002 01:36:26 -0400 (EDT) Received: from unknown(208.10.194.50) by sentry.gw.tislabs.com via smap (V5.5) id xma009280; Thu, 18 Jul 02 05:35:26 GMT Received: by SJCXCH01.hifn.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 22:39:35 -0700 Message-ID: From: Russell Dietz To: RJ Atkinson Cc: IPSec Working Group , SAAG Subject: RE: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors Date: Wed, 17 Jul 2002 22:39:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Wednesday, July 17, 2002, at 09:42 PM, RJ Atkinson wrote: > Russell, > > I'm pretty indifferent to the topic of what ought or ought not be > mandatory-to-implement or maybe even standards-track RFC versus > informational RFC. I am remarkably indifferent to any of the > mathematical parts of your note or Uri's followup. > > I do feel pretty strongly that the above referenced draft ought to be > permitted to be published, at least as an Informational RFC, so that > those folks who choose to implement/deploy it can do so in an > interoperable manner. > > Trying to prevent people from publishing open specifications for > entirely optional-to-implement technology is NOT consistent with > the Internet tradition. I would hope that the RFC Editor would > apply their own good judgement to an individual request to publish > such a document as an Informational RFC if the situation should arise. > > Yours, > > Ran > rja@extremenetworks.com Hello Ran, I totally agree that the Internet tradition of allowing individuals to publish work should continue unchanged. I apologize if I gave off that impression in our note. That was not the intent. We need 'optional' features to be made available to the Internet community in order to allow for potential coordinated field 'trials' and interoperability. The facts around this draft are that it was added to the charter of the IPSec WG as part of the AES cipher support effort. (It is a WG draft!) That linkage has caused misinformation in the original draft to become perceived as pseudo-requirements. The general issue of WG drafts and the connection between this draft and the AES/FIPS 180-2 effort have created a great deal of confusion at some of the implementers. So... the concern is the linkage and the request by the user community for implementation as it is 'going to be a standard soon...' Hope this helps clarify things! Regards, Russ From owner-saag@MIT.EDU Thu Jul 18 01:48:04 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id BAA22649 for ; Thu, 18 Jul 2002 01:48:03 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA12718 for ; Thu, 18 Jul 2002 01:48:04 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id BAA24062; Thu, 18 Jul 2002 01:33:48 -0400 (EDT) Received: by sentry.gw.tislabs.com; id BAA09412; Thu, 18 Jul 2002 01:47:25 -0400 (EDT) Received: from gnat.inet.org(63.108.254.91) by sentry.gw.tislabs.com via smap (V5.5) id xma009407; Thu, 18 Jul 02 05:46:58 GMT Received: from mosquito.inet.org (T23-TNOZAKI.extremenetworks.com [10.4.2.119]) by gnat.inet.org (Postfix) with ESMTP id D079E67103; Wed, 17 Jul 2002 21:54:58 -0400 (EDT) Date: Thu, 18 Jul 2002 01:47:23 -0400 Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG To: Russell Dietz From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Thursday, July 18, 2002, at 01:39 AM, Russell Dietz wrote: > I totally agree that the Internet tradition of allowing individuals to > publish work should continue unchanged. I apologize if I gave off that > impression in our note. That was not the intent. We need 'optional' > features to be made available to the Internet community in order to > allow > for potential coordinated field 'trials' and interoperability. Thank you for that clarification. > The facts around this draft are that it was added to the charter of the > IPSec WG as part of the AES cipher support effort. (It is a WG draft!) > That > linkage has caused misinformation in the original draft to become > perceived > as pseudo-requirements. The general issue of WG drafts and the > connection > between this draft and the AES/FIPS 180-2 effort have created a great > deal > of confusion at some of the implementers. > > So... the concern is the linkage and the request by the user community > for > implementation as it is 'going to be a standard soon...' IETF is not the only standards-body existing. In particular, the US Government's standards (e.g. FIPS) in fact are going to be (or already are; I'm not 100% current on where NIST stands with this) requiring this hash along with AES for USG applications -- regardless of what the IETF decides should be in its Internet Standards-track specification set. So, purely speaking as a capitalist, if I were a vendor that planned to sell an IPsec-based product to the USG (not a small market and their checks don't bounce), I would want to implement this spec without regard to whether the IETF chose to make it an Internet Standards-track specification.[1] Now I'm not arguing for or against this particular draft going onto the IETF standards-track. I *am* gently suggesting that keeping it off the IETF standards-track is very *unlikely* to greatly reduce customer demand for this option. Now debates about whether my market analysis is correct are probably out of scope here, so maybe should be moved to private email or some other non-IETF context. Ran rja@extremenetworks.com [1] Extreme has no IPsec products. No need for anyone to spin up, this really is a hypothetical statement. :-) From jis@MIT.EDU Thu Jul 18 03:00:05 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id DAA23773; Thu, 18 Jul 2002 03:00:05 -0400 (EDT) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id DAA26659; Thu, 18 Jul 2002 03:00:05 -0400 (EDT) Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id DAA23765; Thu, 18 Jul 2002 03:00:03 -0400 (EDT) Message-ID: <3D366774.5040808@mit.edu> Date: Thu, 18 Jul 2002 16:00:04 +0900 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: multipart/mixed; boundary="------------080309080906060702050805" Subject: [saag] Slides from meeting Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------080309080906060702050805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------080309080906060702050805 Content-Type: text/plain; name="saag54.mgp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="saag54.mgp" %deffont "standard" xfont "utopia-medium-r", tfont "georgia.ttf" %default 1 area 90 90, leftfill, size 2, fore "Yellow", back "blue", font "standard", hgap 0 %default 2 size 7, vgap 10, prefix " ", fore "Yellow", back "blue", font "standard" %default 3 size 2, bar "gray70", vgap 10 %default 4 size 5, vgap 30, prefix " ", font "standard" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% %% Default settings that are applied to TAB-indented lines. %% %tab 1 size 5, vgap 40, prefix " ", icon box "green" 50 %tab 2 size 4, vgap 40, prefix " ", icon arc "yellow" 50 %tab 3 size 3, vgap 40, prefix " ", icon delta3 "white" 40 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page %nodefault %size 6.5, font "standard", fore "Yellow", back "Blue" %center IETF54 SAAG MEETING %bar "gray70" 6 15 70 %size 6 Steve Bellovin %size 3 AT&T Research %size 6 Jeffrey Schiller %size 3 Massachusetts Institute of Technology %page Working Groups That Met smime secsh krb-wg pkix ipsec inch Still a BOF, we (the AD's) need to fix this, and we will %page IAB News Crypto Forum Research Group has been chartered cfrg-request@ietf.org %page Presentation Russell Dietz on HMAC-SHA-256-96 %page RFC instructions Life is easier for all concerned if these guidelines are adhered to: http://www.rfc-editor.org/policy.html http://www.ietf.org/ID-nits.html %page Open Mic. %center %xsystem "xclock -geometry %30x30+25+60 -update 1 -bg blue -fg Yellow -hands green" --------------080309080906060702050805-- From owner-saag@MIT.EDU Thu Jul 18 06:27:01 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id GAA26553 for ; Thu, 18 Jul 2002 06:27:01 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id GAA25284 for ; Thu, 18 Jul 2002 06:27:01 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id GAA24698; Thu, 18 Jul 2002 06:12:44 -0400 (EDT) Received: by sentry.gw.tislabs.com; id GAA14574; Thu, 18 Jul 2002 06:26:22 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se(193.180.251.49) by sentry.gw.tislabs.com via smap (V5.5) id xma014569; Thu, 18 Jul 02 10:25:44 GMT Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g6IAQErU007327; Thu, 18 Jul 2002 12:26:14 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id MAA04616; Thu, 18 Jul 2002 12:26:12 +0200 Message-ID: <3D369823.BF21FCC0@era.ericsson.se> Date: Thu, 18 Jul 2002 12:27:47 +0200 From: Mats =?iso-8859-1?Q?N=E4slund?= Organization: Ericsson Research X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Russell Dietz CC: IPSec Working Group , SAAG Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hi Russell Dietz wrote: > > Unfortunately, the current draft is misleading in this regard: > "Using the SHA-256 block cipher, with its increased block size (512 bits) > and increased hash length (256 bits), provides the new algorithm with the > ability to withstand continuing advances in crypto-analytic techniques and > computational capability. It also allows less frequent re-keying, which is > useful for high-speed networks and high-volume applications." > It is our belief that, as currently defined in DRAFT-SHA-256, the use of > SHA-256 does not achieve any of these stated goals. If you want to view SHA-256 as a block cipher, the "512" is to be thought of as the key-size and the 160/256 (SHA1/SHA256) corresponds to the block size. Best, /Mats From owner-saag@MIT.EDU Thu Jul 18 12:22:39 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id MAA01409 for ; Thu, 18 Jul 2002 12:22:38 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA16064 for ; Thu, 18 Jul 2002 12:22:38 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id LAA25227; Thu, 18 Jul 2002 11:59:16 -0400 (EDT) Received: by sentry.gw.tislabs.com; id MAA21742; Thu, 18 Jul 2002 12:12:54 -0400 (EDT) Received: from snake012.odetics.com(198.58.66.53) by sentry.gw.tislabs.com via smap (V5.5) id xma021735; Thu, 18 Jul 02 16:12:17 GMT Received: by snake012.odetics.com with Internet Mail Service (5.5.2655.55) id ; Thu, 18 Jul 2002 09:12:17 -0700 Message-ID: <6F0AA176DA68704884B7507AE6907E180818D7@snake012.odetics.com> From: Christina Helbig To: "'Russell Dietz'" , IPSec Working Group , SAAG Date: Thu, 18 Jul 2002 09:12:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [saag] RE: No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hi Russell, I have looked to the available I-Ds and found only . In this draft a lot of your points is covered, e.g. the claim about re-keying is not more part of this draft, truncation is to 128 bit, comparison to SHA-1 is only about speed... Greetings Christina > -----Original Message----- > From: Russell Dietz [mailto:rdietz@hifn.com] > Sent: Wednesday, July 17, 2002 5:36 PM > To: IPSec Working Group; SAAG > Subject: No need for SHA-2 Packet Authentication - Open > Letter to the WG > a nd Area Directors > > > To the IPSec Working Group and Security Area Directors: > > The purpose of this letter is to comment on an existing > Internet Draft, > draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, > co-authored by S. > Frankel and S. Kelley. This draft, hereafter referred to as > DRAFT-SHA-256 > for brevity, defines how to use the new SHA-256 algorithm > from NIST (FIPS > 180-2) for packet authentication within the ESP and AH > mechanisms of IPSec. > > Our basic argument here is that, while the new SHA-256 algorithm is > definitely useful in other contexts, in fact there is no evidence that > DRAFT-SHA-256 provides any meaningful additional > cryptographic security over > the HMAC-SHA-1-96 algorithm defined in RFC2406 and already in > widespread use > for packet authentication in IPSec. For all we know, quite > the contrary may > be true, as SHA-256 is a new transform and thus has seen > considerably less > public review so far than SHA1 has already received. In any > case, it is > extremely unlikely that HMAC-SHA1 will be the weak point in > any system using > IPSec. Hence, it is not clear that trying to improve its > security makes any > sense, given the costs and instability associated with such a change. > > Unfortunately, the current draft is misleading in this regard: > "Using the SHA-256 block cipher, with its increased block > size (512 bits) > and increased hash length (256 bits), provides the new > algorithm with the > ability to withstand continuing advances in crypto-analytic > techniques and > computational capability. It also allows less frequent > re-keying, which is > useful for high-speed networks and high-volume applications." > It is our belief that, as currently defined in DRAFT-SHA-256, > the use of > SHA-256 does not achieve any of these stated goals. > > First of all, the block size of SHA-256 (512 bits) is > identical to that of > SHA-1, so the first assertion in the quote above is simply > false, although > frankly it would have no relevance if true. Second, there is no known > reason why DRAFT-SHA-256 would in fact allow less frequent > rekeying, using > either 32-bit or 64-bit sequence numbers. Finally, and most > importantly, > while it is true that SHA-256 can output 256 bits, in the > current draft the > HMAC-SHA-256 output is in fact truncated to 96 bits, as is > HMAC-SHA-1 in > RFC2406. For the HMAC-SHA-1-96 and DRAFT-SHA-256 algorithms, > there is every > reason to believe that the limiting factor in security is the > number of bits > of hash included in the packet, not the length before > truncation. The best > attacks known on HMAC-SHA-1-96 and DRAFT-SHA-256 depend only > on the length > after truncation, not the length before truncation. Hence, > the HMAC-SHA-1-96 > and DRAFT-SHA-256 have equivalent security against known > attacks, and there > seems to be little reason to prefer either one over the other, from a > cryptographic perspective. For any given number of output > bits, up to the > SHA-1 limit of 160 bits, this would continue to be the case. If it was > desired to have a MAC value longer than 160 bits, then the > use of SHA-256 > would likely be appropriate, but there is no apparent need > for such a MAC > tag length, according to current knowledge. > > It is possible that the draft was initiated from a fundamental > misunderstanding of Figure 1 (page 3) of the NIST draft FIPS > 180-2. This > figure states that the "security" of SHA-1 is 80 bits, while > the "security" > of SHA-256 is 128 bits. A naive reading of this figure would > thus lead one > to conclude that only SHA-256 is appropriate for use with > AES-128. However, > the figure in question deals with the strength of the hash > functions against > collisions as part of a digital signature scheme. It is > likely that the use > of SHA-256 is very appropriate for the digital signatures used in the > certificates of the IKE exchange used to generate AES-128 and > HMAC-SHA-1-96 > keys for ESP and AH. This is in fact the application for > which SHA-256 was > designed. > > However, while Figure 1 in FIPS 180-2 is correct for digital > signatures, it > has no direct relevance to the issue of packet authentication > in ESP and AH > as addressed in DRAFT-SHA-256. Packet authentication has a completely > different attack model. In particular, there is no known > feasible "birthday > attack" problem in the packet authentication context, as has > been shown by > Krawczyk and others (e.g., "Keying Hash Functions for Message > Authentication" by Bellare, Canetti, and Krawczyk, Crypto '96). > > Since HMAC-SHA1-96 (RFC2406) is already a "MUST" for IPSec > compliance, all > IPSec implementations, hardware or software, already have it and must > continue to support it for many years to come. Any possible > argument that > somehow SHA-256 can replace SHA-1 to save hardware cost is > thus extremely > ill-founded. In fact, quite the opposite is true: adding > DRAFT-SHA-256 as an > IPSec option will only increase hardware cost, with no > accompanying security > benefit. > > We expect that if the WG approved DRAFT-SHA-256, it would be > optional rather > than mandatory. However, there would be a strong risk that > vendors and > their customers might feel compelled to use it out of a > misunderstanding of > the cryptographic issues. Already we have heard potential > customers asking > for support for DRAFT-SHA-256, with the rationale being, "if > IETF approves > it, it must be good". > > Our purpose in submitting this letter is to make sure that > the IPSec working > group has a reasonable understanding of the issues involved in > DRAFT-SHA-256. If the WG decides to approve the draft, we > strongly suggest > that, at a bare minimum, > > a) the inaccurate claims discussed above should be corrected > or removed, > b) the document should be re-worked to clarify the fact that SHA1 is > perfectly adequate, according to current knowledge, > c) the resulting transform should be qualified as > optional-to-implement, not > mandatory, and > d) the draft should make clear under what circumstances the > transform is an > option worth pursuing (e.g. if SHA-1 is broken by advances in > cryptanalysis, > but SHA-256 is not) > > However, given that there is no known cryptographic benefit > to implementing > this proposed standard, we respectfully submit that the IPSec > WG should not > approve this draft. > > Doug Whiting, dwhiting@hifn.com, Hifn > David McGrew, mcgrew@cisco.com, Cisco > Dave Wagner, daw@cs.berkeley.edu, UC Berkeley > Russ Housely, rhousley@rsdsecurity.com, RSA Labs > Niels Ferguson, niels@ferguson.net, MacFergus BV > Thomas Hardjono, thomas.hardjono@verisign.com, Verisign > Scott Fluhrer, fluhrer@cisco.com, Cisco > Jesse Walker, jesse.walker@intel.com, Intel > Mike Sabin, mike.sadin@worldnet.att.net, Independent Consultant > John Kelsey, kelsey.j@ix.netcom.com, Certicom > Russell Dietz, rdietz@hifn.com, Hifn > > Russell Dietz > Hifn, Inc. > pgp-fingerprint: CEE3 58B0 DD09 4EA5 7266 BF1E B5F6 4D1A 4AD1 65B4 > From owner-saag@MIT.EDU Mon Jul 22 13:42:36 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id NAA15128 for ; Mon, 22 Jul 2002 13:42:35 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA14110 for ; Mon, 22 Jul 2002 13:42:35 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id NAA03041; Mon, 22 Jul 2002 13:24:13 -0400 (EDT) Received: by sentry.gw.tislabs.com; id NAA03039; Mon, 22 Jul 2002 13:37:58 -0400 (EDT) Received: from pigeon.verisign.com(65.205.251.71) by sentry.gw.tislabs.com via smap (V5.5) id xma003014; Mon, 22 Jul 02 17:37:04 GMT Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g6MHWNYl012830; Mon, 22 Jul 2002 10:32:23 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 10:39:20 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B3A@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Christina Helbig'" , "'Russell Dietz'" , IPSec Working Group , SAAG Subject: RE: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Date: Mon, 22 Jul 2002 10:39:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Given that the only party for whom SHA-256 use is postulated as being mandated is the US federal government, has anyone from the US federal govt. actually stated that they intend to make SHA-256 a requirement over SHA-1? My understanding is that the new SHA hashes are supplemental to SHA-1 and that the accreditation for SHA-1 is unaffected (at least for the moment).Certainly one would hope to see DSA updated before SHA-1 is withdrawn! Has anyone heard different in this regard? Phill From owner-saag@MIT.EDU Mon Jul 22 20:50:50 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id UAA22551 for ; Mon, 22 Jul 2002 20:50:50 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA01105 for ; Mon, 22 Jul 2002 20:50:50 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id UAA03591; Mon, 22 Jul 2002 20:36:28 -0400 (EDT) Received: by sentry.gw.tislabs.com; id UAA12530; Mon, 22 Jul 2002 20:50:13 -0400 (EDT) Received: from gnat.inet.org(63.108.254.91) by sentry.gw.tislabs.com via smap (V5.5) id xma012512; Tue, 23 Jul 02 00:49:23 GMT Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id EBD3F6711D; Mon, 22 Jul 2002 16:57:37 -0400 (EDT) Date: Mon, 22 Jul 2002 18:13:55 -0400 Subject: Re: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG To: "Hallam-Baker, Phillip" From: RJ Atkinson In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869B3A@vhqpostal.verisign.com> Message-Id: <4FBA2A6A-9DC0-11D6-80FC-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Monday, July 22, 2002, at 01:39 , Hallam-Baker, Phillip wrote: > Given that the only party for whom SHA-256 use is postulated as being > mandated is the US federal government, has anyone from the US federal > govt. > actually stated that they intend to make SHA-256 a requirement over > SHA-1? Yes. I've heard from USG folks that NIST will be making SHA-256 a FIPS requirement (in at least some situations). I don't know whether or claim that such a decision would necessarily mean deprecating SHA-1. My own assumption is that more than one hash could co-exist, each with its own uses. > My understanding is that the new SHA hashes are supplemental to SHA-1 > and > that the accreditation for SHA-1 is unaffected (at least for the > moment).Certainly one would hope to see DSA updated before SHA-1 is > withdrawn! Requiring FOO in some applications would not necessarily imply deprecating BAR. I think you are coupling things together that are not necessarily coupled in the quoted text above. But, as I noted originally, USG customers might prefer SHA-256 over SHA-1-bis regardless of what the IETF says is an IETF standard. Ran rja@extremenetworks.com From owner-saag@MIT.EDU Tue Jul 23 13:56:16 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id NAA07249 for ; Tue, 23 Jul 2002 13:56:16 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA04416 for ; Tue, 23 Jul 2002 13:56:16 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id NAA05583; Tue, 23 Jul 2002 13:39:30 -0400 (EDT) Received: by sentry.gw.tislabs.com; id NAA00561; Tue, 23 Jul 2002 13:53:17 -0400 (EDT) Received: from peacock.verisign.com(65.205.251.73) by sentry.gw.tislabs.com via smap (V5.5) id xma000549; Tue, 23 Jul 02 17:52:25 GMT Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g6NHmipS028464; Tue, 23 Jul 2002 10:48:45 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 10:54:39 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D1CB479@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" Cc: IPSec Working Group , SAAG Subject: RE: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Date: Tue, 23 Jul 2002 10:54:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: This discussion is futile. If USG want to make a requirement in this area it is up to the USG to make the request to the working group, in particular it is the responsibility of NIST which has the primary responsibility for liasing with standards organizations. Phill > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Monday, July 22, 2002 6:14 PM > To: Hallam-Baker, Phillip > Cc: IPSec Working Group; SAAG > Subject: Re: [saag] RE: No need for SHA-2 Packet Authentication - Open > Let ter to the WG a nd Area Directors > > > > On Monday, July 22, 2002, at 01:39 , Hallam-Baker, Phillip wrote: > > Given that the only party for whom SHA-256 use is > postulated as being > > mandated is the US federal government, has anyone from the > US federal > > govt. > > actually stated that they intend to make SHA-256 a requirement over > > SHA-1? > > Yes. I've heard from USG folks that NIST will be making > SHA-256 a FIPS > requirement (in at least some situations). I don't know whether or > claim that > such a decision would necessarily mean deprecating SHA-1. My own > assumption > is that more than one hash could co-exist, each with its own uses. > > > My understanding is that the new SHA hashes are > supplemental to SHA-1 > > and > > that the accreditation for SHA-1 is unaffected (at least for the > > moment).Certainly one would hope to see DSA updated before SHA-1 is > > withdrawn! > > Requiring FOO in some applications would not necessarily imply > deprecating BAR. > I think you are coupling things together that are not > necessarily coupled > in the quoted text above. > > But, as I noted originally, USG customers might prefer SHA-256 over > SHA-1-bis > regardless of what the IETF says is an IETF standard. > > Ran > rja@extremenetworks.com > From owner-saag@MIT.EDU Tue Jul 23 14:51:27 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id OAA08396 for ; Tue, 23 Jul 2002 14:51:26 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA08851 for ; Tue, 23 Jul 2002 14:51:26 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id OAA05815; Tue, 23 Jul 2002 14:37:03 -0400 (EDT) Received: by sentry.gw.tislabs.com; id OAA02242; Tue, 23 Jul 2002 14:50:49 -0400 (EDT) Received: from gnat.inet.org(63.108.254.91) by sentry.gw.tislabs.com via smap (V5.5) id xma002231; Tue, 23 Jul 02 18:50:39 GMT Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 052C367103; Tue, 23 Jul 2002 10:59:03 -0400 (EDT) Date: Tue, 23 Jul 2002 14:51:11 -0400 Subject: Re: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG To: "Hallam-Baker, Phillip" From: RJ Atkinson In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40D1CB479@vhqpostal.verisign.com> Message-Id: <27E6A30F-9E6D-11D6-97EC-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Tuesday, July 23, 2002, at 01:54 , Hallam-Baker, Phillip wrote: > This discussion is futile. Possibly. > If USG want to make a requirement in this area it is up to the USG to > make > the request to the working group, in particular it is the > responsibility of > NIST which has the primary responsibility for liasing with standards > organizations. IETF does not recognise organisational representation, only individual representation. Participation in IETF is entirely voluntary for everyone. Any organisation can create internal standards for itself without IETF if they choose to do so. It is preferable that IETF be open enough and productive enough that folks would choose to bring proposals to IETF, but it certainly is not a requirement that anyone bring their standards work to IETF. It would be quite reasonable for interested folks to publish an informational or experimental RFC should the IPsec WG choose not to standardise a particular transform of interest to some community of interested folks -- to circle back to the point I've been trying to make for the past several days. Ran rja@extremenetworks.com From owner-saag@MIT.EDU Tue Jul 23 15:35:18 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id PAA09172 for ; Tue, 23 Jul 2002 15:35:17 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA18328 for ; Tue, 23 Jul 2002 15:35:18 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id PAA05933; Tue, 23 Jul 2002 15:17:33 -0400 (EDT) Received: by sentry.gw.tislabs.com; id PAA03875; Tue, 23 Jul 2002 15:31:19 -0400 (EDT) Received: from pigeon.verisign.com(65.205.251.71) by sentry.gw.tislabs.com via smap (V5.5) id xma003861; Tue, 23 Jul 02 19:30:30 GMT Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g6NJPorQ008656; Tue, 23 Jul 2002 12:25:50 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 12:32:47 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D1CB4C2@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: RJ Atkinson , "Hallam-Baker, Phillip" Cc: IPSec Working Group , SAAG Subject: RE: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Date: Tue, 23 Jul 2002 12:32:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Once again: 1. DoD may not be bound by NIST rules but AES/SHA-256 is a NIST standard. Ergo if DoD takes it into its head to demand a NIST standard it likely does so because it regards NISt to be authoritative. 2. IETF rules may state that working group members speak for themselves. However that does not mean that a working group should take a work item on the assertion by J. Random Bozo that the USG demands it when we can ask the organization that USG appointed to make such assertions. 3. USG policy (including DoD) is currently to use COTS wherever possible. If USG departments are having to specify non-standard extensions to COTS software and NIST has failed to even inform the standards body that they have a requirement then NIST is not doing its job. I pretty much dislike the way that this discussion takes place in which one party assumes the authority of USG when USG has said nothing on the matter at all, either directly or indirectly. If the obvious route of asking Tim Polk or Bill Burr what the situation is is considered objectionable something is wrong. Phill From owner-saag@MIT.EDU Tue Jul 23 16:13:11 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id QAA09761 for ; Tue, 23 Jul 2002 16:13:11 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA03834 for ; Tue, 23 Jul 2002 16:13:11 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id PAA06000; Tue, 23 Jul 2002 15:58:47 -0400 (EDT) Received: by sentry.gw.tislabs.com; id QAA04846; Tue, 23 Jul 2002 16:12:34 -0400 (EDT) Received: from gnat.inet.org(63.108.254.91) by sentry.gw.tislabs.com via smap (V5.5) id xma004835; Tue, 23 Jul 02 20:12:05 GMT Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 2262467103; Tue, 23 Jul 2002 12:20:31 -0400 (EDT) Date: Tue, 23 Jul 2002 16:12:37 -0400 Subject: Re: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG To: "Hallam-Baker, Phillip" From: RJ Atkinson In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40D1CB4C2@vhqpostal.verisign.com> Message-Id: <88807402-9E78-11D6-97EC-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Tuesday, July 23, 2002, at 03:32 , Hallam-Baker, Phillip wrote: > 1. DoD may not be bound by NIST rules but AES/SHA-256 is a NIST > standard. > Ergo if DoD takes it into its head to demand a NIST standard it > likely does so because it regards NISt to be authoritative. Disagree. Any operator/user that requests something from its vendors or from IETF likely does so because they think it is a good idea for their situation. Clearly your mileage varies from mine on this aspect. > 2. IETF rules may state that working group members speak for themselves. > However that does not mean that a working group should take a work > item on the assertion by J. Random Bozo that the USG demands it when we > can > ask the organization that USG appointed to make such assertions. Being on the SAAG list only, I haven't seen anyone suggest that any WG *standardise* anything. No doubt I've missed some context here by not being on the IPsec WG list. RECAP: This thread was started on the SAAG list by someone suggesting *not standardising* something and further apparently (since clarified) trying to prevent that something from even being published. I responded saying that preventing publication was nearly always a bad idea and that market requirements tend to have a life of their own (largely independent of what standards bodies might proclaim from on high) -- with an example scenario. It appears that some folks (e.g. Phillip) misconstrued providing that example as a request for standardisation, which is unfortunate. SUMMARY: To be clear, and repetitive with my earlier note, I don't care one iota what does or doesn't get standardised for algorithms in IPsec. I'm totally indifferent to that dimension. I care a lot that people are allowed to publish reasonable documents as non-standard RFCs if IETF chooses not to standardise them. I also noted that RFC Editor has the power to make that decision to publish Informational or Experimental RFCs. > 3. USG policy (including DoD) is currently to use COTS wherever > possible. > If USG departments are having to specify non-standard extensions to > COTS software and NIST has failed to even inform the standards body that > they have a requirement then NIST is not doing its job. Or IETF hasn't done its job to listen to operators/users to get the right feature set into the standards. If the latter, no doubt that will be the first time that has happened in IETF in recent years. Any number of other things are also possibly happening in this situation. Since IETF does NOT have organisational members and IAB has no liaison established with NIST, it isn't obvious to me how "NIST" can officially communicate anything with IETF. So I don't see how criticising NIST (or folks who happen to work there) is either appropriate or helpful. I'll be putting future notes from Phillip on this thread into /dev/null, so he can have the last word and the SAAG list can resume its normal happy silence. :-) Cheers, Ran rja@extremenetworks.com From owner-saag@MIT.EDU Wed Jul 24 16:21:08 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id QAA29959 for ; Wed, 24 Jul 2002 16:21:07 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA05155 for ; Wed, 24 Jul 2002 16:21:08 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id QAA08598; Wed, 24 Jul 2002 16:04:28 -0400 (EDT) Received: by sentry.gw.tislabs.com; id QAA06150; Wed, 24 Jul 2002 16:18:15 -0400 (EDT) Received: from mail.rsasecurity.com(204.167.114.123) by sentry.gw.tislabs.com via smap (V5.5) id xma006129; Wed, 24 Jul 02 20:17:45 GMT Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for sentry.gw.tislabs.com [192.94.214.100]) with SMTP; 24 Jul 2002 20:17:20 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA13454; Wed, 24 Jul 2002 16:18:16 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6OKGAB02885; Wed, 24 Jul 2002 16:16:10 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TP404J8>; Wed, 24 Jul 2002 16:18:15 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.32]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TP404J5; Wed, 24 Jul 2002 16:18:12 -0400 From: "Housley, Russ" To: RJ Atkinson Cc: ipsec@lists.tislabs.com, saag@lists.tislabs.com Message-Id: <5.1.0.14.2.20020724140348.0212dd78@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Jul 2002 14:13:03 -0400 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [saag] Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Ran: We are not trying to stifle innovation, nor are we trying to suppress SHA-256. SHA-256 has an important place, but this is not it. SHA-256 was developed to support applications that need a longer output value. SHA-1 generates a 160-bit output value. In our view, SHA-1 should be used unless a longer output value is needed. In the proposal, the hash value is truncated to 128 bits, so there is no benefit from the more complicated hash function. I would support the use of SHA-256 if the final output were longer than 160 bits. Russ At 12:41 AM 7/18/2002 -0400, RJ Atkinson wrote: >On Wednesday, July 17, 2002, at 08:35 PM, Russell Dietz wrote: > >>To the IPSec Working Group and Security Area Directors: >> >>The purpose of this letter is to comment on an existing Internet Draft, >>draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, co-authored by S. >>Frankel and S. Kelley. This draft, hereafter referred to as DRAFT-SHA-256 >>for brevity, defines how to use the new SHA-256 algorithm from NIST (FIPS >>180-2) for packet authentication within the ESP and AH mechanisms of IPSec. > >Russell, > >I'm pretty indifferent to the topic of what ought or ought not be >mandatory-to-implement or maybe even standards-track RFC versus >informational RFC. I am remarkably indifferent to any of the >mathematical parts of your note or Uri's followup. > >I do feel pretty strongly that the above referenced draft ought to be >permitted to be published, at least as an Informational RFC, so that >those folks who choose to implement/deploy it can do so in an >interoperable manner. > >Trying to prevent people from publishing open specifications for >entirely optional-to-implement technology is NOT consistent with >the Internet tradition. I would hope that the RFC Editor would >apply their own good judgement to an individual request to publish >such a document as an Informational RFC if the situation should arise. > >Yours, > >Ran >rja@extremenetworks.com > > >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From owner-saag@MIT.EDU Sun Jul 28 20:18:04 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id UAA11454 for ; Sun, 28 Jul 2002 20:18:04 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA24887 for ; Sun, 28 Jul 2002 20:18:04 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id UAA17490; Sun, 28 Jul 2002 20:03:36 -0400 (EDT) Received: by sentry.gw.tislabs.com; id UAA27133; Sun, 28 Jul 2002 20:17:29 -0400 (EDT) Received: from auemail1.lucent.com(192.11.223.161) by sentry.gw.tislabs.com via smap (V5.5) id xma027104; Mon, 29 Jul 02 00:16:39 GMT Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6T0H9512073; Sun, 28 Jul 2002 20:17:09 -0400 (EDT) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id UAA22851; Sun, 28 Jul 2002 20:17:07 -0400 (EDT) Received: from there by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id UAA22847; Sun, 28 Jul 2002 20:17:06 -0400 (EDT) Message-Id: <200207290017.UAA22847@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: saag@lists.tislabs.com Subject: Re: [saag] Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors Date: Sun, 28 Jul 2002 20:15:31 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: <5.1.0.14.2.20020724140348.0212dd78@exna07.securitydynamics.com> In-Reply-To: <5.1.0.14.2.20020724140348.0212dd78@exna07.securitydynamics.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id UAA11454 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: On Wednesday 24 July 2002 14:13, Housley, Russ wrote: > .............. In our view, SHA-1 should be > used unless a longer output value is needed. In the proposal, the > hash value is truncated to 128 bits, so there is no benefit from the > more complicated hash function. > > I would support the use of SHA-256 if the final output were longer > than 160 bits. And to emphasize - it's for the cases when MAC of longer than 160 bits is needed, NOT when more than 160 bits of key material.... -- Regards, Uri-David -=-=-<>-=-=- From owner-saag@MIT.EDU Wed Jul 24 17:02:07 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id RAA00703 for ; Wed, 24 Jul 2002 17:02:06 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA12378 for ; Wed, 24 Jul 2002 17:02:06 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id QAA08657; Wed, 24 Jul 2002 16:47:43 -0400 (EDT) Received: by sentry.gw.tislabs.com; id RAA07362; Wed, 24 Jul 2002 17:01:31 -0400 (EDT) Received: from barbar.esat.kuleuven.ac.be(134.58.56.153) by sentry.gw.tislabs.com via smap (V5.5) id xma007353; Wed, 24 Jul 02 21:00:53 GMT Received: from lien (preneel@lien.esat.kuleuven.ac.be [134.58.189.73]) by barbar.esat.kuleuven.ac.be (8.9.3/8.9.3) with ESMTP id XAA02031; Wed, 24 Jul 2002 23:01:19 +0200 (METDST) Date: Wed, 24 Jul 2002 23:01:19 +0200 (CEST) From: Bart Preneel To: Russell Dietz cc: IPSec Working Group , SAAG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Two small corrections below. 1) Some attacks on MAC algorithms DO depend on the length after truncation, but not as claimed: there is an attack that becomes more efficient (for a given hash function) if this length increases! 2) Moreover, there is indeed a birthday attack on HMAC (the proof by Bellare et al. stops at the birtday bound). It is not a realistic attack, but a key search for a 128-bit key is not realistic either. This does not change the conclusion, but I believe that using incorrect arguments to support the correct conclusion is not really helpful. Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 69 Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- On Wed, 17 Jul 2002, Russell Dietz wrote: > First of all, the block size of SHA-256 (512 bits) is identical to that of > SHA-1, so the first assertion in the quote above is simply false, although > frankly it would have no relevance if true. Second, there is no known > reason why DRAFT-SHA-256 would in fact allow less frequent rekeying, using > either 32-bit or 64-bit sequence numbers. Finally, and most importantly, > while it is true that SHA-256 can output 256 bits, in the current draft the > HMAC-SHA-256 output is in fact truncated to 96 bits, as is HMAC-SHA-1 in > RFC2406. For the HMAC-SHA-1-96 and DRAFT-SHA-256 algorithms, there is every > reason to believe that the limiting factor in security is the number of bits > of hash included in the packet, not the length before truncation. The best > attacks known on HMAC-SHA-1-96 and DRAFT-SHA-256 depend only on the length > after truncation, not the length before truncation. Hence, the HMAC-SHA-1-96 > and DRAFT-SHA-256 have equivalent security against known attacks, and there > seems to be little reason to prefer either one over the other, from a > cryptographic perspective. For any given number of output bits, up to the > SHA-1 limit of 160 bits, this would continue to be the case. If it was > desired to have a MAC value longer than 160 bits, then the use of SHA-256 > would likely be appropriate, but there is no apparent need for such a MAC > tag length, according to current knowledge. > > [...] > > However, while Figure 1 in FIPS 180-2 is correct for digital signatures, it > has no direct relevance to the issue of packet authentication in ESP and AH > as addressed in DRAFT-SHA-256. Packet authentication has a completely > different attack model. In particular, there is no known feasible "birthday > attack" problem in the packet authentication context, as has been shown by > Krawczyk and others (e.g., "Keying Hash Functions for Message > Authentication" by Bellare, Canetti, and Krawczyk, Crypto '96). > [...] The best known attacks on any iterated MAC algorithm with a k-bit key, an n-bit internal memory, and an m-bit result (some other conditions apply): guess the MAC value: probability of success 2**-m find the key by exhaustive search: 2**k birthday attack [1]: 2**(n/2) text-MAC pairs and 2**(n-m+1) chosen texts The best known attacks on HMAC-SHA-1-96: guess the MAC value: probability of success 2**-96 find a 160-bit key by exhaustive search: 2**160 birthday attack [1]: 2**80 known text-MAC pairs and 2**65 chosen texts It is safe to say that these attacks are infeasible or not relevant for at least 15 years, so there is no need to upgrade. The best known attacks on DRAFT-SHA-256 with an m-bit result: guess the MAC: probability of success 2**-m find a 256-bit key by exhaustive search: 2**256 birthday attack [1]: 2**128 text-MAC pairs and 2**(256-m+1) chosen texts I believe that the following holds: * It is likely that better attacks than the above attack exist for DRAFT-SHA-256. Note that the complexities are huge. * It is likely that DRAFT-SHA-256 is more secure than HMAC-SHA-1-96. * Both seem to offer a more than adequate security level (even if I would like to see more research on MAC-like properties of SHA-type hash functions). I agree that there is no cryptographic reason to upgrade. [1] B. Preneel, P.C. van Oorschot, "On the security of iterated Message Authentication Codes," IEEE Transactions on Information Theory, Vol. 45, No. 1, January 1999, pp. 188-199. ------------------------------------------------------------------------------- From tim.polk@nist.gov Thu Aug 1 13:40:26 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id NAA09714 for ; Thu, 1 Aug 2002 13:40:26 -0400 (EDT) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA23477 for ; Thu, 1 Aug 2002 13:40:26 -0400 (EDT) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g71HeOZb014898 for ; Thu, 1 Aug 2002 13:40:25 -0400 (EDT) Message-Id: <4.2.0.58.20020801131720.01c53300@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 01 Aug 2002 13:37:16 -0400 To: saag@mit.edu From: Tim Polk Subject: Re: [saag] Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors In-Reply-To: <5.1.0.14.2.20020724140348.0212dd78@exna07.securitydynamics .com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Folks, I was rather nervous when this topic came up in Yokohama. Being under-prepared on cryptographic topics is always recipe for disaster. After conferring with my colleagues, I have discovered that my knowledge was every bit as limited as I feared. I stated at the SAAG that SHA-1 was faster than SHA-256. This turns out to be an incomplete and misleading statement. SHA-256 and SHA-1 are round-based hash algorithms. SHA-256 requires 64 rounds as opposed to 80 rounds for SHA-1. Depending upon the implementation platform, it may be possible to perform the rounds in comparable time. In such a case, SHA-256 would be faster. Please don't repeat my mistake and attempt to generalize regarding the performance of these two algorithms. It is difficult to quantify the performance of algorithms, since there are so many factors. (In software processors these factors include word sizes, internal instruction pipelines, and numbers of registers. In hardware, different factors may apply.) There are certainly specific implementation environments where each algorithm would present advantages. Thanks, Tim From canetti@watson.ibm.com Thu Aug 8 11:05:26 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id LAA00260 for ; Thu, 8 Aug 2002 11:05:25 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA27498 for ; Thu, 8 Aug 2002 11:05:25 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g78F2DF06266; Thu, 8 Aug 2002 11:02:13 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g78F2DH28162; Thu, 8 Aug 2002 11:02:13 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id LAA28746; Thu, 8 Aug 2002 11:02:11 -0400 Date: Thu, 8 Aug 2002 11:02:11 -0400 From: Ran Canetti Message-Id: <200208081502.LAA28746@ornavella.watson.ibm.com> To: authtime@nist.gov, ietf-ipsra@vpnc.org, ietf-kink@vpnc.org, ietf-krb-wg@anl.gov, ietf-openpgp@imc.org, ietf-otp@research.telcordia.com, ietf-pkix@imc.org, ietf-sacred@imc.org, ietf-smime@imc.org, ietf-ssh@netbsd.org, ietf-tls@lists.certicom.com, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com, msec@securemulticast.org, saag@mit.edu, w3c-ietf-xmldsig@w3.org Cc: canetti@ornavella.watson.ibm.com, mcgrew@cisco.com Subject: [saag] A new crypto forum at the IRTF Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Folks, this note is to announce the formation of a new IRTF Research Group, called "Crypto Forum Research Group" (CFRG). The group is intended to answer the need for a single forum where cryptographers, network security experts, and protocol designers can exchange ideas and investigate the use of cryptographic techniques for network protocols in general and for the IETF in particular. CFRG is of course NOT intended as a replacement for the work done at the IETF Working Groups in standardizing actual protocols. Rather, it the group provides a forum where general techniques and tools can be developed and scrutinized to the benefit of multiple Working Groups. Apart from disseminating the understanding of cryptographic techniques within the IETF, the outputs of CFRG are expected to come in the form of informational RFCs (in the tradition of, e.g., RFCs 1321 [MD5] and 2104 [HMAC]). You are cordially invited to join the mailing list and bring forth the cryptographic question that deprived you of sleep lately. The list is open. To reduce spam, the chairs will moderate mails from non-members. For Charter, more information, and subscription instructions, see http://www.irtf.org/cfrg. Best, David Mcgrew and Ran Canetti, CFRG co-chairs. PS. We'd like to thank Mark Baugher for his great help in setting up the new research group. From baijian@hosix.ntu-kpi.kiev.ua Wed Oct 16 06:33:07 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id GAA24720 for ; Wed, 16 Oct 2002 06:33:06 -0400 (EDT) Received: from relay1.ntu-kpi.kiev.ua (www.ntu-kpi.kiev.ua [212.111.192.161]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA05349 for ; Wed, 16 Oct 2002 06:33:04 -0400 (EDT) Received: from hosix.ntu-kpi.kiev.ua (if100Mbit.hosix.ntu-kpi.kiev.ua [10.100.5.6]) by relay1.ntu-kpi.kiev.ua (Postfix) with ESMTP id D58271A868 for ; Wed, 16 Oct 2002 13:32:58 +0300 (EEST) Received: from baijian (shiv.hosix.ntu-kpi.kiev.ua [10.100.23.101]) by hosix.ntu-kpi.kiev.ua (8.12.6/8.12.5) with SMTP id g9GAWrT4079480 for ; Wed, 16 Oct 2002 13:32:55 +0300 (EEST) (envelope-from baijian@hosix.ntu-kpi.kiev.ua) Message-ID: <002301c274ff$be251920$6517640a@baijian> From: "Jian Bai" To: Date: Wed, 16 Oct 2002 13:35:24 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C27518.E1B8BA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Subject: [saag] (no subject) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: UbJG MIME 8qJ=5D>_SP:\6`2?7VO{O"!# ------=_NextPart_000_0020_01C27518.E1B8BA40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGVsbG8NCg== ------=_NextPart_000_0020_01C27518.E1B8BA40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNDYyLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5oZWxsbzwvRk9OVD48L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0020_01C27518.E1B8BA40-- From mouse@Sparkle.Rodents.Montreal.QC.CA Wed Oct 16 07:01:39 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id HAA25163 for ; Wed, 16 Oct 2002 07:01:39 -0400 (EDT) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA10457 for ; Wed, 16 Oct 2002 07:01:39 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id HAA29171; Wed, 16 Oct 2002 07:00:30 -0400 (EDT) From: der Mouse Message-Id: <200210161100.HAA29171@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 16 Oct 2002 12:54:53 +0200 (CEST) To: baijian@hosix.ntu-kpi.kiev.ua Cc: saag@mit.edu Subject: Re: [saag] (no subject) In-Reply-To: <002301c274ff$be251920$6517640a@baijian> References: <002301c274ff$be251920$6517640a@baijian> Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: > UbJG MIME 8qJ=5D>_SP:\6`2?7VO{O"!# 026YD965D+B`@4V%Y(&]N(0`! > aGVsbG8NCg== UXVpdGUgc28uICBXZWxjb21lIHRvIHNhYWchCg== TWlnaHQgSSByZWNvbW1lbmQgeW91IHVzZSBwbGFpbiB0ZXh0LCB0aG91Z2g/Cg== /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From Weimer@CERT.Uni-Stuttgart.DE Wed Oct 16 14:58:47 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id OAA09511 for ; Wed, 16 Oct 2002 14:58:47 -0400 (EDT) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA02245 for ; Wed, 16 Oct 2002 14:58:47 -0400 (EDT) Received: from rusfw by Mail.CERT.Uni-Stuttgart.DE with local (Exim 4.04) id 181tNN-000207-00; Wed, 16 Oct 2002 20:58:37 +0200 To: der Mouse Cc: baijian@hosix.ntu-kpi.kiev.ua, saag@mit.edu Subject: Re: [saag] (no subject) References: <002301c274ff$be251920$6517640a@baijian> <200210161100.HAA29171@Sparkle.Rodents.Montreal.QC.CA> From: Florian Weimer Date: Wed, 16 Oct 2002 20:58:37 +0200 In-Reply-To: <200210161100.HAA29171@Sparkle.Rodents.Montreal.QC.CA> (der Mouse's message of "Wed, 16 Oct 2002 12:54:53 +0200 (CEST)") Message-ID: <8765w22ote.fsf@Login.CERT.Uni-Stuttgart.DE> Lines: 10 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: der Mouse writes: > TWlnaHQgSSByZWNvbW1lbmQgeW91IHVzZSBwbGFpbiB0ZXh0LCB0aG91Z2g/Cg== QW5kIHBsZWFzZSB1c2UgN2JpdCBvciBxdW90ZWQtcHJpbnRhYmxlIGFzIENURS4= -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 From owner-saag@MIT.EDU Mon Oct 21 11:08:15 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id LAA06294 for ; Mon, 21 Oct 2002 11:08:15 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA11948 for ; Mon, 21 Oct 2002 11:08:15 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id LAA17894 Mon, 21 Oct 2002 11:07:35 -0400 (EDT) Received: by sentry.gw.tislabs.com; id LAA04342; Mon, 21 Oct 2002 11:08:10 -0400 (EDT) Received: from h-135-207-30-102.research.att.com(135.207.30.102) by sentry.gw.tislabs.com via smap (V5.5) id xma004327; Mon, 21 Oct 02 15:07:34 GMT Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id B05AA4CEA2 for ; Mon, 21 Oct 2002 11:07:34 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA21300 for ; Mon, 21 Oct 2002 11:07:34 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 7F92B7B6A for ; Mon, 21 Oct 2002 11:07:33 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: saag@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 11:07:33 -0400 Message-Id: <20021021150733.7F92B7B6A@berkshire.research.att.com> Subject: [saag] draft NIST Special Publication 800-38B available for public comment (fwd) Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: ------- Forwarded Message Date: Mon, 21 Oct 2002 09:08:47 -0400 To: "NIST Crypto Mailing List": ; From: Morris Dworkin Subject: draft NIST Special Publication 800-38B available for public comment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: b025898e220709262528cee8a34d4b08 X-Spam-Status: No, hits=0.4 required=5.0 tests=X_AUTH_WARNING,TO_MALFORMED version=2.31 X-Spam-Level: The draft NIST Special Publication 800-38B, "Recommendation for Block Cipher Modes of Operation: the RMAC Authentication Mode" is available for public comment, from a link at http://csrc.nist.gov/publications/drafts.html. The document specifies RMAC, the MAC algorithm that was submitted to NIST by Jaulmes, Joux, and Valette. Comments are welcome, to EncryptionModes@nist.gov, by December 2, 2002. Regards, Morris Dworkin ------- End of Forwarded Message --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From ravi.sahita@intel.com Mon Nov 11 20:52:53 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id UAA06036 for ; Mon, 11 Nov 2002 20:52:52 -0500 (EST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA16410 for ; Mon, 11 Nov 2002 20:52:52 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gAC1mVm18424 for ; Tue, 12 Nov 2002 01:48:31 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gAC1tUR25222 for ; Tue, 12 Nov 2002 01:55:30 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002111117532123530 for ; Mon, 11 Nov 2002 17:53:21 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 17:52:51 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F0B3491C2@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'saag@mit.edu'" , "'disfi@lists.intel.com'" Cc: "Sahita, Ravi" Date: Mon, 11 Nov 2002 17:52:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [saag] Distributed endpoint firewall control Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Hi all, On behalf of a number of people, I want to present some thoughts for distributed end-point firewall control at the upcoming SAAG meeting. This email is to send some material before the meeting - two strawman drafts follow - the first contrasts this approach with the perimeter firewall approach. If the problem statement in the first draft interests you, read on to the second strawman draft which covers some basic requirements from our discussions. I've also setup a mailing list disfi@lists.intel.com - To subscribe, send email to listserv@lists.intel.com with the command "subscribe disfi" in the message body. I would like to also call for an informal (bar?) bof on Wednesday Nov 20th at 5:30pm. Meet at the bulletin board and go from there. thanks, -- Ravi Network Working Group A. D. Keromytis Internet Draft Columbia University draft-keromytis-disfi-compare-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses some of the shortcomings of perimeter firewalls and the reasons for employing end-point (or distributed) firewall functionality in the network, either as an alternative or coexisting with traditional network access controls. 1. Introduction Distributed firewalls [Bel99,IKBS] represent an alternative network access control mechanism to "traditional" perimeter firewalls [BC94]. Policy is enforced in a decentralized manner by the different components of the network, acting in a coordinated manner. Distributed network access control (DNAC) can be employed either as an alternative or in conjunction with perimeter firewalls, and can employ different mechanisms and protocols, as well as heterogeneous elements. This document discusses some of the shortcomings of perimeter firewalls and the reasons for employing end-point (or distributed) firewall functionality in the network, either as an alternative or coexisting with traditional network access controls. 1.1. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 2. Shortcomings of Perimeter Firewalls In this section, we list several shortcomings of Perimeter Firewalls (PFs) and briefly discuss them. It is important to bear in mind that PFs fundamentally depend on restrictions in the network topology, such that they can examine all traffic exchanged between a protected network and the public network, and enforce a security policy (typically access control). 2.1. Performance Because PFs depend on restrictions in network topology to enforce a security policy, it has to examine all traffic exchanged between the protected network and the public network. Thus it can become a performance bottleneck, especially if it also has to perform network encryption to accomodate Virtual Private Networks (VPNs), virus checking, or other CPU-intensive services. Load-balancing techniques can help to some extend, but the complexity of state-sharing and synchronization in firewall clusters is a real limiting factor. 2.2. Protection from Insiders Likewise, because of the dependence on the network topology, a PF can only enforce a policy on traffic that traverses it. Thus, traffic exchanged among nodes in the protected network cannot be controlled. This gives an attacker that is already an insider or can somehow bypass the firewall (see Section 2.6) complete freedom to act. One obvious solution is to deploy multiple firewalls, in which case they must be coordinated and control in a consistent manner. 2.3. End-to-end Protocol Properties There are several stateful protocols that use random ports for data transfers, which require the PF to actively monitor (and reconstruct) the control message sequences for these protocols. This increases the complexity and decreases the performance of the PF, and thus the whole (protected) network. The fundamental problem is that IP was designed as a lean network substrate that would simply act as a packet carrier; all protocol state is maintained at the communication end-points. A PF breaks this model by definition (since it needs to peek inside packets to make a policy decision); for some protocols, the ability to make that decision requires reconstruction of part of the state that is readily available at the end-points. 2.4. Network Encryption Increasingly, end-to-end cryptographic protocols such as IPsec [RFC2401], TLS [RFC2246], and SSH are being used to protect (encrypt) communications between nodes. PFs are hard-pressed to enforce a security or intrusion detection (e.g., virus scanning) policy in these situations, as they cannot strip the encryption. Potential solutions break this end-to-end model of security (key escrow, firewall as encryption end-point or trusted man-in-the-middle, etc.) with a corresponding loss of assurance and performance. 2.5. Mobility / Telecommuting / Infrastructure Sharing In certain scenarios, nodes or users that are topologically outside the protected network must be treated as if they were inside it. Examples include users on the road, telecommuters, and Intranet configurations. In all these cases, parts (or all) of the protected infrastructure need to be exposed in a controlled manner to remote entities. PFs make this a complicated subject, especially in the presence of multihoming and fine-grain resource sharing (and corresponding access control) requirements. 2.6. Closure Due to several trends in networking such as site multihoming, abundant dial-up access, and wide-scale (insecure) wireless deployment, administrators cannot be assured that all traffic exchanged between the protected and the public network will be examined by a PF: an attacker that manages to access the protected network through a user-installed wireless access point has complete freedom of action. 2.7. Defense in Depth Following classic army doctrine, prudent security engineering argues for multiple defensive lines ("defense in depth") as a way to minimize the risk of a successful breach of the perimeter. PFs alone cannot (by definition) provide this functionality; additional mechanisms are necessary inside the protected network. 3. Security Considerations This draft describes some shortcomings of perimeter firewalls, and argues for the need for distributed firewall functionality. There are several security issues in such an architecture, including policy robustness, secure distribution and control, coordination, management, and resilience to intrusions or insider attacks (this is not intended to be a detailed or exclusive list). These issues will be addressed in separate documents of the working group (should there be one). 4. IANA Considerations No requirements are placed on IANA at this stage. Acknowledgements This document came out of discussions at the Distributed Firewalls mailing list, which can be foiund at disfi@lists.intel.com To subscribe on the list, send email to listserv@lists.intel.com with the command "subscribe disfi" in the message body. References: [Bel99] S.M. Bellovin, "Distributed Firewalls", USENIX ;login magazine, special issue on security, November 1999. [BC94] Bellovin, S.M. and W.R. Cheswick, "Firewalls and Internet Security: Repelling the Wily Hacker", Addison-Wesley, 1994. [IKBS] Ioannidis, S. and Keromytis, A.D., and Bellovin, S.M. and J.M. Smith, "Implementing a Distributed Firewall", Proceedings of Computer and Communications Security (CCS), pp. 190-199, November 2000, Athens, Greece. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] T. Dierks and C. Allen, "The TLS Protocol Version 1.0," Internet Engineering Task Force, RFC 2246, January 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Author's address: Angelos D. Keromytis Columbia University, CS Department 515 CS Building 1214 Amsterdam Avenue, Mailstop 0401 New York, New York 10027-7003 Phone: +1 212 939 7095 Email: angelos@cs.columbia.edu Expiration and File Name This draft expires in May 2003 Its file name is draft-keromytis-disfi-compare-00.txt ---------------------------------------------------------------------- Network Working Group Ravi Sahita Internet Draft Intel Corp. Distributed/End-Point Firewall Control (DEFCon) Requirements draft-many-defcon-reqs-00.txt Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the requirements for the architecture and a distributed framework for end-point firewall control (DEFCon). This draft also discusses requirements for the individual pieces in the framework. Perimeter firewalls are predominant in enterprise networks but do not provide the protection a mission critical network needs against misuse or abuse from nodes inside the network. Additionally, A wireless infrastructure makes every host vulnerable since in that case access is not fundamentally restricted by infrastructure. Likewise, traffic is increasingly being encrypted end-to-end using SSL, IPSec, etc. where viruses/worms/confidential information can also be hidden from the security components. This requires the perimeter firewall to become a man-in-the-middle for all secure sessions, which breaks the end-to-end principle and thus renders many protocols useless since they are inevitably blocked. A host-based firewall on nodes in the enterprise network protects the network from inside out. This approach does not preclude perimeter firewalls. Instead, it provides defense-in-depth and reduces the load on perimeter firewalls. The host-based approach also upholds the end-to-end theme since it allows traffic to be securely encrypted end-to-end, yet still be assured safe from infection, compromise and attack. 1. Introduction Perimeter firewalls are software or hardware entities applying various forms of ACLs to network traffic exiting or entering a controlled network. These transit nodes tend to be a bottleneck due to amount of traffic they handle. Also, a lot of traffic exists in the network that these transit nodes do not touch since they don't exit the network or enter the network from an external network. These firewalls have no control over this traffic. State based protocols that use random ports for data transfer after the control messages are exchanged also cause perimeter firewalls to be additionally complicated and require state keeping. As e-commerce transactions become cost-effective and prevalent, there is a need [Page 1] DEFCon Requirements October 2002 to open parts of the enterprise network to customers and/or suppliers, this dictates an additional layer of complexity. End-to- End encryption of traffic is affected due to the perimeter firewalls having to terminate the secure connections. This document describes the requirements for DEFCon and the various elements that constitute the framework. Using this approach, the security policies can be defined in a flexible but secure way to be corporate wide as well as tailored to specific sections of the network. Business relationships can be translated to dynamic rules installed possibly as a overlay, without change in the baseline security rules of other nodes. In this document, Section 2 describes the terms used in this document and other related documents. Section 3 defines the overall architectural requirements of a DEFCon based network. Section 4 discusses the requirements for the components in the framework. Section 5 describes the expected typical operational of the DEFCon framework. Section 7 outlines security requirements for the DEFCon framework. 2. Terminology The following terms are defined for use in this requirements draft and other related drafts. 2.1. DEFCon rule A set of fields that are used to classify the application traffic entering or exiting a DEFCon based host. [2] defines this as, a set of terms and/or criteria used for the purpose of separating or categorizing. This is accomplished via single-or multi-field matching of traffic header and/or payload data. 2.2. DEFCon action A set of possible actions that can be taken on a packet after it has been classified. [2] defines action as, definition of what is to be done to enforce a policy rule, when the conditions of the rule are met. Policy actions may result in the execution of one or more operations to affect and/or configure network traffic and network resources. 2.3. DEFCon rule An association of conditions and corresponding actions. The rules are applied to the network traffic to and from the host, and on a match corresponding actions are taken on the traffic. 2.4. Firewall A software or hardware entity that applies a set of access control rules to network traffic. 2.5. End-Point Firewall A firewall on an end-point client or server in an administrative domain of a network that applies security policies to network traffic entering or exiting that end-point. 2.6. DEFCon control service [Page 2] DEFCon Requirements October 2002 An OA&M (operations, administration and management) function that allows administrators to setup firewall rules for firewalls on network end-points. This function also receives state information from the end-point firewalls under its control. 2.7. DEFCon control station A node running the DEFCon control service. Multiple such control stations may exist for scalability reasons. 2.8. DEFCon client A component in the DEFCon framework that is controlled by the DEFCon control service. This component receives the access control rules from such a control service. This component also reports state to the control service that it is associated with. 2.9. DEFCon protocol Mechanism defined by wire format data structures and associated rules that are used to communicate between a DEFCon client and a DEFCon control service. 2.10. DEFCon or Distributed/End-Point Firewall CONtrol A framework for Distributed/End-point Firewall CONtrol. This framework includes multiple end-point firewall clients, possibly in different domains within an overall administrative domain, controlled by an administrative station in the same network. This framework also defines the protocols used for communication between the control service and the end-point firewalls. It also enforces the security requirements to meet the overall requirements. 2.11. DEFCon association The process by which a DEFCon client associates with a DEFCon control service. 2.12. DEFCon rule conflict resolution The process by which a DEFCon client detects rule conflicts due to incorrect or overlapping specification of rules. 2.13. DEFCon rule validation The process by which a DEFCon control station validates the set of rules on the end-point firewalls under its control. This capability can be used to check network rule compliance. 2.14. DEFCon rule feedback The process by which a DEFCon control station recognizes events from other control stations or from the end-point firewalls under its control and applies state changes to a set of end-point firewalls or communicates the state information to another control station to take action. [Page 3] DEFCon Requirements October 2002 3. DEFCon Architecture Requirements +---------------------------------------------+ | +---------------+ | | Firewall application | DEFCon client | | | +---------------+ | | | +---------------------------------------------+ / \ | | | ---|-----------------|------------------------- | | | \ / +----------------------------+ | | | Driver | | +----------------------+ | | | Local Rules | | | +----------------------+ | | | +----------------------------+ / \ | | | +----|---------------|-------+ | | | | | | NIC \ / | | +----------------------+ | | | Remote Rules | | | +----------------------+ | | / \ | | +------------------------------+ | | | | | Control station | | +--|--+ +-\ /--+ | | +------------------+ | | | | | | | | | | | | | Rx | | Tx | | | | DEFCon control | | | +-----+ +------+ | | | service | | +---/\-----------------|-----+ | +------------------+ | | | +----------/ \--------|--------+ | | | | | | | | ----|-----------------\ /---------------------|--------\ /---- DEFCon protocol Network There are multiple end-points in a network. The DEFCon architecture hence consists of multiple end-point firewalls. These end-point firewalls must be controlled by an administrative control station. The communication between the remote control station and the end- point firewall must be authenticated, encrypted and must have integrity control. An assumption is that the group of end-point firewalls associated with a remote control station belongs to some logical group in the network. This logical group may be a VLAN, a subnet or some other ad-hoc group established via other mechanisms. The association of an end-point firewall with a control station must be done securely via deterministic rules defined in the protocol requirements section. To achieve a scalable architecture, a remote control station must also be capable of controlling another peer control station. With [Page 4] DEFCon Requirements October 2002 this capability a high level security operations center could control a set of remote stations that in turn control the end-point firewalls in their domain. This approach breaks up the manageability of large domains into smaller problems. However, this approach has additional security implications. The communication protocol used MUST account for secure communication between a master control station and a slave control station. The association of a slave control station with a master control station must be done securely via deterministic rules defined in the protocol requirements section. On the client side, the end-point firewall may be designed as an embedded component, a local component or a combination. The local component is typically under the control of a local application. Parts of the embedded component may be de-coupled from the operating system for added security. 4. Component Requirements 4.1. DEFCon protocol 4.1.1 The protocol state machinery for the client must be isolated such that the local driver cannot access the protocol state machine or any data received by the protocol state machine. This ensures that the firewall rules of the domain are not visible to the local users of the host. Also, this ensures that the rules are not blocked from deployment in any way. 4.1.2 After a cold start, the protocol must allow for the DEFCon client to be associated with the control station for the domain (or subnet) it belongs to via a secure mechanism. 4.1.3 The discovery mechanism in the protocol MUST be secure so that a rogue control station cannot get a DEFCon client under its control. On the other hand, a rogue DEFCon client MUST not be able to connect to the control station. 4.1.4 Due to any failure if the DEFCon client looses connectivity with the control station it is associated with, the system should fail safely and disable traffic from entering or leaving the end- point. 4.1.5 Network traffic MUST NOT be allowed to pass through the DEFCon end-point until it is associated successfully with a control station in the domain. 4.1.6 The transport between the DEFCon client and a control station must be reliable and connection-oriented so that persistent state can be maintained between the DEFCon client and the control station. 4.1.7 The DEFCon client MUST be connected to only one control station at any given time. [Page 5] DEFCon Requirements October 2002 4.1.8 The protocol MUST allow the control station to be connected to multiple DEFCon clients. 4.1.9 The DEFCon client and the domain control station MUST exchange regular heartbeat messages securely to ensure that connectivity (with the correct entities) is maintained. 4.1.10 The security mechanism used for communication should be self-updating so that sampling based attacks over time can be defeated. 4.1.11 All data exchanged over the protocol should be authenticated. 4.1.12 All data exchanged over the protocol should be encrypted. 4.1.13 All data exchanged over the protocol should be checked for integrity. 4.1.14 The data exchanged over the protocol should be based on an extensible and independent data model. No protocol operations should be expressed in data. 4.1.15 The control station MUST be able to push rules and rule updates to the DEFCon client. 4.1.16 The DEFCon client must report the status of all operations performed by the control station via a message. 4.1.17 The protocol MUST allow a control station to renew operation with a stable state in the case of power loss or other failure on both the end-point or the control station. 4.1.18 The protocol MUST ensure that the rules pushed to the DEFCon clients in a message are transaction oriented, and hence are applied fully or an error is reported. 4.1.19 The control station MUST be able to query any DEFCon client for its state. 4.1.20 The DEFCon client must be able to report its state changes or events to the control station in an unsolicited manner. 4.1.21 Once a session is established, the protocol MUST only enable the control station to break the connection, the DEFCon client MUST not be able to close the connection via the protocol. Note that the [Page 6] DEFCon Requirements October 2002 DEFCon client may be physically disconnected which may cause the connection to be abruptly broken. 4.1.22 The protocol must have version identification to account for updates to the standard for interoperability. 4.1.23 The protocol must be able to carry rule-sets describing traffic filters based on header fields and generic patterns to be looked for in traffic. 4.1.24 The protocol must be able to specify for which direction of traffic the rules are applied at. 4.1.25 The protocol must be able to operate in different modes. I.e., between a DEFCon client and a control station and between a control station and another control station (for example a Security Operations Center or SOC communicating with a control station). This is to build scalability into the system. 4.1.26 The protocol must define mechanisms to mitigate replay attacks on control messages. 4.1.27 Rule conflicts MUST not be handled by the protocol. These are dependent on the data (rules) that is pushed from the control station and should be handled by the control station logic. 4.2. Local DEFCon client requirements TBD 4.3. Remote DEFCon control service requirements TBD 5. Expected Typical Operation [Page 7] DEFCon Requirements October 2002 6. Security Requirements Since the motivation for this work is primarily around security control, the following sections are to discuss the security requirements around each component of the DEFCon framework in detail. 6.1 DEFCon Protocol Data carried over the DEFCon protocol is required to be encrypted, authenticated and have integrity information. The protocol must protect against replay attacks by using challenge response type messages. If this is not done a rogue client could hijack an existing DEFCon association. Integrity is required to ensure that DEFCon messages are not accidentally or maliciously altered or destroyed. The result of a lack of data integrity enforcement in an un-trusted environment could be that a rogue server will alter the messages sent by the valid server and setup wrong rules on the DEFCon clients under the servers control and could potentially cause a denial of service attack on the entire network. The protocol must encrypt the messages to ensure confidentiality of DEFCon rules. If encryption is not used in an un-trusted environment, anybody can sniff the packets and know the current rule-base being used by the administrator and plan attacks as described in earlier sections. 6.2 DEFCon client The DEFCon client should fail safely on an authorization failure from a control service. These failed attempts should be logged via one-way events to the local OS. Authentication is also needed from the DEFCon client to the control server. Since, if the client is not authenticated, the confidentiality of the rules sent to this client may be compromised. Some level of flow control is needed on the association process, since multiple rogue clients could inundate a control server thus causing valid clients to not be updated with latest rules leaving clients vulnerable. 6.3 DEFCon server Authentication is needed from the DEFCon server to the DEFCon client. If the server is not authenticated, it could remove all rules from the remote client and render the framework useless. [Page 8] DEFCon Requirements October 2002 7. References 7.1 Normative References 7.2 Informative References [1] S. Bradner, "Key words to use in the RFCs", RFC 2119. Mar 1997. [2] Westernized, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. [3] Bellovin, S.M., "Distributed Firewalls", Login, November 1999, pp. 37-39 [4] Bellovin, S.M., Smith, J., Keromytis, A., Loannidis, S., "Implementing a Distributed Firewall", http://www.cis.upenn.edu/~angelos/Papers/df.ps [5] Payne, C., Markham, T., "Architecture and applications for a distributed embedded firewall" Computer Security Applications Conference, 2001. ACSAC 2001. Proceedings 17th Annual, 2001 Page(s): 329 -336 [6] Markham, T., Payne, C., "Security at the network edge: a distributed firewall architecture" DARPA Information Survivability Conference & Exposition II, 2001. DISCEX '01. Proceedings, Volume: 1 , 2001 Page(s): 279 -286 vol.1 8. Authors' Addresses Ravi Sahita Intel Corp. 2111 NE 25th Avenue Hillsboro, OR 97124 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. [Page 9] DEFCon Requirements October 2002 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Table of Contents 1. Introduction....................................................1 2. Terminology.....................................................2 3. DEFCon Architecture Requirements................................4 4. Component Requirements..........................................5 4.1. DEFCon protocol...............................................5 4.2. Local DEFCon client requirements..............................7 TBD................................................................7 4.3. Remote DEFCon control service requirements....................7 5. Expected Typical Operation......................................7 6. Security Requirements...........................................8 7. References......................................................9 7.1 Normative References...........................................9 7.2 Informative References.........................................9 8. Authors' Addresses..............................................9 From julihato@perkom.co.id Mon Nov 11 21:29:36 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id VAA06644 for ; Mon, 11 Nov 2002 21:29:36 -0500 (EST) Received: from jktmail1.biz.net.id (jktmail1.biz.net.id [202.169.33.221]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA28304 for ; Mon, 11 Nov 2002 21:29:27 -0500 (EST) Received: from perkom.co.id [202.169.39.141] by jktmail1.biz.net.id with ESMTP (SMTPD32-6.05) id A83AAF501AA; Tue, 12 Nov 2002 09:32:26 +0700 Received: from hato [202.169.39.141] by perkom.co.id [202.169.39.142] with SMTP (MDaemon.PRO.v5.0.7.R) for ; Tue, 12 Nov 2002 09:31:18 +0700 Message-ID: <010901c289f3$8785db30$590b0a80@hato> From: "Juli Hato" To: References: <200211120154.UAA06092@jis.mit.edu> Date: Tue, 12 Nov 2002 09:30:37 +0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MDRemoteIP: 202.169.39.141 X-Return-Path: julihato@perkom.co.id X-MDaemon-Deliver-To: saag@mit.edu Subject: [saag] Re: saag digest, Vol 1 #147 - 1 msg Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: ----- Original Message ----- From: To: Sent: Tuesday, November 12, 2002 8:54 AM Subject: saag digest, Vol 1 #147 - 1 msg > Send saag mailing list submissions to > saag@mit.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://jis.mit.edu/mailman/listinfo/saag > or, via email, send a message with subject or body 'help' to > saag-request@mit.edu > > You can reach the person managing the list at > saag-admin@mit.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of saag digest..." > > ---------------------------------------------------------------------------- ---- > Today's Topics: > > 1. Distributed endpoint firewall control (Sahita, Ravi) > ---------------------------------------------------------------------------- ---- > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > > From salki@motorola.com Tue Oct 29 11:15:28 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id LAA21820 for ; Tue, 29 Oct 2002 11:15:28 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08513 for ; Tue, 29 Oct 2002 11:15:28 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA01718 for ; Tue, 29 Oct 2002 09:15:27 -0700 (MST)] Received: [from zgr01exm01.corp.mot.com (zgr01exm01.corp.mot.com [10.162.168.200]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA16688 for ; Tue, 29 Oct 2002 09:11:44 -0700 (MST)] Received: by zgr01exm01.corp.mot.com with Internet Mail Service (5.5.2654.52) id <49D901WN>; Tue, 29 Oct 2002 18:15:21 +0200 Message-ID: <332B652C3E8ED411A4EA00B0D049C44C93718C@zgr01exm01.corp.mot.com> From: Salkintzis Apostolis-Y1026C To: "'saag@mit.edu'" Cc: Salkintzis Apostolis-Y1026C Date: Tue, 29 Oct 2002 18:15:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-7" Subject: [saag] Call for book chapter on "IP Security in Mobile Environments" Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Dear all - I'm currently editing and co-authoring a new book entitled "Wireless Internet: Technologies and Applications", which is going to be published by CRC Press next year. Proposals for a chapter on "IP Security in Mobile Environments" are solicited, which would include an estimation of the chapter length, as well as an tentative ToC. A short bio of the prospective author(s) is also mandatory. The first draft must be ready by end of February 2003. Note that the book targets novice readers (e.g. students) as well as more advanced readers (e.g. engineers), who want to get familiar with the primary aspects of wireless Internet. Therefore, all chapters should be easy to read, addressing both fundamental aspects as well as more advanced aspects. The balance between fundamental / advanced aspects is up to the authors, but I would prefer more weight on tutorial aspects. Looking forward to your response. Regards, Apostolis --- Dr. Apostolis Salkintzis GPRS/UMTS System Design & Standards Motorola 32 Kifissias Ave, Athens, GR-15125 Greece From ravi.sahita@intel.com Wed Nov 20 09:01:26 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id JAA04107 for ; Wed, 20 Nov 2002 09:01:25 -0500 (EST) Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA06097 for ; Wed, 20 Nov 2002 09:01:25 -0500 (EST) Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id gAKE2a907304 for ; Wed, 20 Nov 2002 14:02:36 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002112005593501500 for ; Wed, 20 Nov 2002 05:59:35 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 06:01:23 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F0B34922E@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Endpoint Firewall Controll (IETF)'" Cc: "'saag@mit.edu'" , "Sahita, Ravi" Date: Wed, 20 Nov 2002 06:01:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [saag] Informal bof logistics Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: We can use the "Consulate" room at 17:45 today (Wednesday) for the informal bof. Ravi From ravi.sahita@intel.com Tue Nov 26 02:24:39 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id CAA26161 for ; Tue, 26 Nov 2002 02:24:39 -0500 (EST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA23912 for ; Tue, 26 Nov 2002 02:24:39 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gAQ7K3220773 for ; Tue, 26 Nov 2002 07:20:03 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gAQ7R9L03616 for ; Tue, 26 Nov 2002 07:27:09 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002112523251917896 for ; Mon, 25 Nov 2002 23:25:19 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 23:24:38 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F0B349279@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'saag@mit.edu'" Cc: "Sahita, Ravi" Date: Mon, 25 Nov 2002 23:24:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [saag] my slides from the saag session Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Distributed End-point Firewall Control Ravi Sahita disfi@lists.intel.com Outline - Presentation of problem statement draft - Outcome of informal BOF held yesterday - Related work - Sub-issues - Next steps - Logistics Motivation - Perimeter Firewalls - No control over internal traffic except what it sees crossing the perimeter - Minimal context information and large number of sessions - Encrypted traffic is a problem - No consideration for external traveling nodes - Needed deeper inspection - hard to do at that scale - Application level proxies break end-to-end principle Motivation (contd.) - Firewalls on end-points - Have the required context, state information - Can decrypt traffic and examine, upholds end-to-end principle - Provide defense in depth - Enables fine granular control to open networks - Ability to stop attacks from spreading at the fan out points - Co-operation with perimeter approaches provides the ability to apply service based security policies on computing and network nodes and correlate events Problem Statement - End-point firewall control - Lack of a standards around - Rule specification - Rule distribution - Rule enforcement - Another control domain - Integration with existing control domains - Potentially large number of nodes - Requires scalable solution - Co-operation with other security devices Outcome of informal BOF - strong support for work - no plans to reinvent a protocol and language if not required - interest in the policy engine influencing other components like virus scanners - centralized vs. de-centralized approaches - handling rule conflicts - how will trusted platforms be used when available - open source IPSP implementation available - support in IPv6 wg to push firewalls to end-points Related work - Distributed firewalls (Nov 1999 issue of login:, pp. 37-39.) - Steve Bellovin - www.research.att.com/~smb/papers/ccs-df.pdf - Sotiris Ioannidis, Angelos Keromytis, Steve Bellovin, and Jonathan Smith - www.cis.upenn.edu/~dsl/STRONGMAN - Sotiris Ioannidis, et al. - www.acsac.org/2001/abstracts/thu-1330-a-payne.html - Tom Markham, Charles Payne - govt.argreenhouse.com/SmartFirewalls/ - Raj Rajagopalan Sub-issues - Secure discovery of end-point firewalls - Topology independent rule association - Rule specification - Network and application rules - Provisioning - Functionality requirements Next Steps - Continue charter, issues discussion on mailing list - Continue work on straw man drafts on mailing list - problem statement - draft-keromytis-disfi-compare-00.txt - functional, protocol, language requirements - draft-many-defcon-reqs-00.txt - existing solutions reused (not yet started) - Proposal to Security ADs for formal BOF - Mailing list details on next slide Distributed End-point Firewall Control Mailing List - disfi@lists.intel.com - To subscribe, send email to listserv@lists.intel.com with "subscribe disfi" in the message body From aboba@internaut.com Mon Dec 23 08:54:48 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id IAA14192 for ; Mon, 23 Dec 2002 08:54:48 -0500 (EST) Received: from internaut.com ([64.38.134.99]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA07804 for ; Mon, 23 Dec 2002 08:54:47 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBNCl0g22628 for ; Mon, 23 Dec 2002 04:47:00 -0800 Date: Mon, 23 Dec 2002 04:47:00 -0800 (PST) From: Bernard Aboba To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [saag] EAP binding problem statement: request for feedback Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: At IETF 55, the attendees at the EAP WG meeting indicated an interest in working on the EAP compound binding problem. A first step toward that goal would be to take on the problem statement document as a WG work item: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt However, before we do that, we would like to get comments on the draft itself. Please send comments to the EAP WG mailing list (eap@frascone.com) and the authors. From rdd@cert.org Mon Dec 23 10:55:36 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id KAA16544 for ; Mon, 23 Dec 2002 10:55:36 -0500 (EST) Received: from franklinus.red.cert.org (franklinus.red.cert.org [192.88.209.16]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA12983 for ; Mon, 23 Dec 2002 10:55:35 -0500 (EST) Received: from timotheus.indigo.cert.org (timotheus.indigo.cert.org [10.60.10.6]) by franklinus.red.cert.org (8.11.6/8.11.6/1.5) with ESMTP id gBNFtYN26485; Mon, 23 Dec 2002 10:55:34 -0500 Received: from [10.10.10.74] (ox.blue.cert.org [10.10.10.74]) by timotheus.indigo.cert.org (8.9.3/8.9.3/2.15) with ESMTP id KAA11852; Mon, 23 Dec 2002 10:55:33 -0500 (EST) Date: Mon, 23 Dec 2002 10:55:33 -0500 From: Roman Danyliw To: inch@nic.surfnet.nl, saag@mit.edu, ietf@ietf.org Message-ID: <264396892.1040640933@[10.10.10.74]> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [saag] INCH WG Interim Meeting, Feb. 9, 2002 Sender: saag-admin@mit.edu Errors-To: saag-admin@mit.edu X-BeenThere: saag@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: Incident Handling WG (INCH) Interim Meeting =========================================== The INCH WG will be holding an interim meeting on February 9, 2002. This meeting is the weekend prior to the FIRST Technical Colloquium, being held in the same city. Time: SUNDAY, February 9, 2002 at 0900-??? Location: Basic Hotel Kungsgatan 27 Uppsala, Sweden Chair: Roman Danyliw Security Area Advisor: Jeffrey Schiller ---[ AGENDA ]-------------------------------------------------------- A formal agenda will be sent out in January, but the intent is to discuss: - The new I-D that is to be created from the two current data model requirements drafts, - The data model (draft-ietf-inch-iodef-00.txt) I-D, and - Early implementation experience. ----[ LOCATION ]------------------------------------------------------ Basic Hotel Kungsgatan 27 Uppsala, Sweden Phone: +46-18-480-5000 WWW: http://www.basichotel.com Single Room 990 SEK / approx. 110 USD / night Double Room 1200 SEK / approx. 133 USD / night The meeting will be held in a conference room at the Basic Hotel. Additional logistical information about Uppsala, Sweden can be found here: http://www.first.org/tc/feb2003/#hotel http://www.first.org/tc/feb2003/#transport There will be no wired or wireless connectivity provided. ----[ MAILING LIST ]---------------------------------------------------- Post: inch@nic.surfnet.nl Archive: http://listserv.surfnet.nl/archives/inch.html Subscribe: send mail to listserv@nic.surfnet.nl with "subscribe inch " in the body