[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