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

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