Subject: [Cfrg] draft-irtf-cfrg-advice-00.txt and related work

From: "David A. Mcgrew" <[email-masked]>
Date: Wed, 19 Feb 2003 14:28:43 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "Catherine A. Meadows" <[email-masked]>
Date: Fri, 21 Feb 2003 17:05:31 -0500 (EST)

Dear David: 

Thanks much for your comments on my draft; they give me some useful

> 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?

> proven secure.  If there are such pitfalls, it would be great to have a

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.   
> dissemination of useful results :-)  Perhaps we can find someone interested in

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