From mailnull@www1.ietf.org Mon Feb 3 03:03:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00560 for ; Mon, 3 Feb 2003 03:03:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1388nC00577 for cfrg-archive@odin.ietf.org; Mon, 3 Feb 2003 03:08:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1388nJ00572 for ; Mon, 3 Feb 2003 03:08:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00548 for ; Mon, 3 Feb 2003 03:03:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13878J32500; Mon, 3 Feb 2003 03:07:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1385UJ32294 for ; Mon, 3 Feb 2003 03:05:30 -0500 Received: from sunbeam.cs.biu.ac.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00523 for ; Mon, 3 Feb 2003 03:00:05 -0500 (EST) Received: from biu-xjbs42banj6.herzberg.name ([132.70.4.58]) by sunbeam.cs.biu.ac.il with ESMTP id h1383eu07137 for ; Mon, 3 Feb 2003 10:03:40 +0200 (IST) Message-Id: <5.1.1.6.0.20030203095522.00aacaf8@mailhost.cs.biu.ac.il> X-Sender: herzbea@mailhost.cs.biu.ac.il X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 03 Feb 2003 10:09:56 +0200 To: cfrg@ietf.org From: Amir Herzberg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Cfrg] Deadline for Security in Distribute Computing - This Thursday! Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Dear Colleagues, Due to the many requests for an extension, the program chair has agreed to move the deadline for submission to PODC'03, and therefore also for the special track on Security in Distributed Computing. The new deadline is this THURSDAY, FEBRUARY 6. I think this could be a really great event due to the convenient location (Boston), key note lectures (By Lampson, Micali, Anderson, Lamport, Lynch, Meyer and Wright - at least the first three on security), two security tutorials, and the opportunity for interaction between the distributed computing, security and crypto communities. And I'm sure there will be interesting presentations and discussions. Even if you can't submit, you should plan to attend. As before, the Call For Papers can be found at http://www.podc.org/podc2003/security-track-cfp.html Instructions for how to submit electronically: http://www.podc.org/podc2003/cfp.html#how We look forward to your submissions! See you in Boston on July. Best regards, and apologies for cross-posting (as well as for sending this reminder too late...), Amir Herzberg Chair of the Security in Distributed Computing Track -------------------------------------------------------------------------------------------------------------------------------- Amir Herzberg http://amir.herzberg.name _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Wed Feb 19 17:27:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11202 for ; Wed, 19 Feb 2003 17:27:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JMYFs15453 for cfrg-archive@odin.ietf.org; Wed, 19 Feb 2003 17:34:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMYFp15450 for ; Wed, 19 Feb 2003 17:34:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11191 for ; Wed, 19 Feb 2003 17:27:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMX6p15415; Wed, 19 Feb 2003 17:33:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMVhp15379 for ; Wed, 19 Feb 2003 17:31:43 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11152 for ; Wed, 19 Feb 2003 17:24:55 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1JMSYB6023742; Wed, 19 Feb 2003 14:28:35 -0800 (PST) Received: from MCGREWW2K (stealth-10-34-251-100.cisco.com [10.34.251.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AEH85535; Wed, 19 Feb 2003 14:24:11 -0800 (PST) From: "David A. Mcgrew" To: Cc: Date: Wed, 19 Feb 2003 14:28:43 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Cfrg] draft-irtf-cfrg-advice-00.txt and related work Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Catherine, I wanted to close the loop on a couple of comments on your draft and some related documents. Your draft rightly recommends that protocol authors describe the security properties that their protocols provide. In order to do this, we need a consistent terminology. RFC 2828, the "Internet Security Glossary", could be invaluable in this regard. It is extensive and precise. Of course, it's not exhaustive (for example, the secure rtp authors found that they needed to define their own terms rather than rely on it). It would be nice if we could reference glossaries that covered other specialized areas such as the cryptographic literature, that of group security, IP DoS and so on. Another potential resource is Rescorla and Korver's "Guidelines for Writing RFC Text on Security Considerations", draft-iab-sec-cons-03.txt. This is a draft and not an RFC, but it contains a lot of useful descriptions. IMO, it would also be interesting for your draft to cover not only how to describe protocols so that they can be analyzed, but also to describe protocol constructs that are amenable to analysis. All other things equal, we want to avoid constructs that complicate a security model to the point that it can't be proven secure. If there are such pitfalls, it would be great to have a description of them. On a related topic, I'd also be interested to see a list of abstract protocols that have been proven to be secure, that concrete protocol designers could use straightforwardly. There have been a lots of interesting flaws found in real protocols via formal analysis, and I'm sure that many protocol designers would appreciate a map that showed the known shortcuts around the landmines. Of course I realize that's a big topic that goes well beyond the scope of your draft, but I feel justified in my role as CFRG chair of encouraging the dissemination of useful results :-) Perhaps we can find someone interested in writing such a draft. David _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Fri Feb 21 17:08:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16765 for ; Fri, 21 Feb 2003 17:08:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LMFrn25681 for cfrg-archive@odin.ietf.org; Fri, 21 Feb 2003 17:15:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LMFrp25678 for ; Fri, 21 Feb 2003 17:15:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16762 for ; Fri, 21 Feb 2003 17:08:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LME4p25539; Fri, 21 Feb 2003 17:14:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LMAMp25416 for ; Fri, 21 Feb 2003 17:10:22 -0500 Received: from itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16558 for ; Fri, 21 Feb 2003 17:02:37 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with SMTP id RAA24111; Fri, 21 Feb 2003 17:06:27 -0500 (EST) Received: from itd.nrl.navy.mil ([132.250.196.100]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.0.1.45) with SMTP id M2003022117062718100 ; Fri, 21 Feb 2003 17:06:27 -0500 Received: from liverwurst.fw5540.net (liverwurst [10.0.3.31]) by itd.nrl.navy.mil (8.9.0/8.9.0) with ESMTP id RAA28214; Fri, 21 Feb 2003 17:05:32 -0500 (EST) From: "Catherine A. Meadows" Received: (from meadows@localhost) by liverwurst.fw5540.net (8.9.0/8.8.8) id RAA04758; Fri, 21 Feb 2003 17:05:31 -0500 (EST) Date: Fri, 21 Feb 2003 17:05:31 -0500 (EST) Message-Id: <200302212205.RAA04758@liverwurst.fw5540.net> To: cfrg@ietf.org, mcgrew@cisco.com Subject: Re: [Cfrg] draft-irtf-cfrg-advice-00.txt and related work Cc: meadows@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Dear David: Thanks much for your comments on my draft; they give me some useful insights into how to improve it. My responses follow: > Your draft rightly recommends that protocol authors describe the security > properties that their protocols provide. In order to do this, we need a > consistent terminology. > RFC 2828, the "Internet Security Glossary", could be invaluable in this regard. > It is extensive and precise. Of course, it's not exhaustive (for example, the > secure rtp authors found that they needed to define their own terms rather than > rely on it). It would be nice if we could reference glossaries that covered > other specialized areas such as the cryptographic literature, that of group > security, IP DoS and so on. > > Another potential resource is Rescorla and Korver's "Guidelines for Writing RFC > Text on Security Considerations", draft-iab-sec-cons-03.txt. This is a draft > and not an RFC, but it contains a lot of useful descriptions. I spent the last couple of days looking through both documents. They do indeed have a lot of relevant information, and I will put in references to both of them and point out how they can be used. If there are any other glossaries or other references that would be helpful, I would certainly appreciate learning about them. Is there anything else all you out there in cfrg can recommend? > IMO, it would also be interesting for your draft to cover not only how to > describe protocols so that they can be analyzed, but also to describe protocol > constructs that are amenable to analysis. All other things equal, we want to > avoid constructs that complicate a security model to the point that it can't be > proven secure. If there are such pitfalls, it would be great to have a > description of them. This is something that I can and should put in. In general, I think this is more a question of design choices than particular constructs: e.g., you should avoid too many versions and choice points, you should aim for modularity, etc. A lot of these affect ease of implementation and interoperability as well. > > On a related topic, I'd also be interested to see a list of abstract protocols > that have been proven to be secure, that concrete protocol designers could use > straightforwardly. There have been a lots of interesting flaws found in real > protocols via formal analysis, and I'm sure that many protocol designers would > appreciate a map that showed the known shortcuts around the landmines. Of > course I realize that's a big topic that goes well beyond the scope of your > draft, but I feel justified in my role as CFRG chair of encouraging the > dissemination of useful results :-) Perhaps we can find someone interested in > writing such a draft. > > David This would certainly be a great list to have. We would have to be careful what we mean when we say "proven" secure however: that is, with respect to what assumptions, what threat model, etc. For example, there are a lot of formal protocol analyses that do not take into account of the possibility of the compromise of old session keys, etc. We would also need to be explicit about what properties have actually been proved. One reference that might be of interest in this respect is a new web site that went up last November, the Security Protocol Open Repository (or SPORE) at http://www.lsv.ens-cachan.fr/spore/. Its main purpose is to provide a set of benchmarks for protocol analysis tools, but it also has references to proofs of security as well, and attacks, if any have been found. Cathy _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg