[Cfrg] draft-irtf-cfrg-advice-00.txt and related work
"David A. Mcgrew" <mcgrew@cisco.com> Wed, 19 February 2003 22:27 UTC
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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@optimus.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@optimus.ietf.org>; 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 <cfrg@ietf.org>; 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" <mcgrew@cisco.com>
To: meadows@itd.nrl.navy.mil
Cc: cfrg@ietf.org
Date: Wed, 19 Feb 2003 14:28:43 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFGENFFHAA.mcgrew@cisco.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 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: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=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
- [Cfrg] draft-irtf-cfrg-advice-00.txt and related … David A. Mcgrew
- Re: [Cfrg] draft-irtf-cfrg-advice-00.txt and rela… Catherine A. Meadows