Steve,
On Sep 22, 2004, at 6:52 AM, Steven M. Bellovin wrote:
In message <69CA0970-0C99-11D9-BDE1-0003935495EC at cisco.com>, "David A. McGrew"
writes:Hilarie,
On Sep 17, 2004, at 3:33 PM, The Purple Streak, Hilarie Orman wrote:
I'm trying to develop a framework for making recommendations for using crypto algorithms, as discussed on this list in past weeks.
sounds like an interesting and useful project.
The general categories are shaping up as follows, and I'd like comments on the plan:
1. Algorithm has been shown to have non-trivial flaws, do not use (do not offer, do not accept).
2. Algorithm has been shown to have non-trivial flaws but is safe if used carefully. DO NOT offer, but MAY accept.
3. Algorithm can be broken by brute force in a "short time". It is not recommended, but MAY be used if the security considerations justify it on the basis of a well-contained risk environment and a need for it (performance, backward compatibility). Any protocols using it MUST also have a MUST IMPLEMENT algorithm that is RECOMMENDED for all uses.
I agree with the intent here. I do wonder who will enforce the first MUST in the last sentence, though.
The IESG enforces it -- we won't approve a document that fails that test. Note carefully the distinction between "must implement" and "must use". (Also note that the IESG has no control over what people actually build; all we can do is say "this is our best professional judgment and if you want to be RFC-compliant here's what you have to do.")
Algorithms in this class must have an attack resistance of at least 64 bits.
There is a lot of definition hidden in the phrase "attack resistance". For each algorithm, it will depend on key size, the amount of data protected by each key, the size of the authentication tag (for MACs), and possibly other parameters. An example of an "other" parameter is the length of the largest message that is authenticated, which impacts the security of some MACs.
I have recently been reviewing some of the security results for block
cipher modes (in the formal, concrete security model) and would like to
connect these results to recommended parameter choices somehow. One
problem with doing this is the fact that some current practices would
be verboten were we to enforce these results. Many practitioners would
regard the formal results as too pessimistic, because in those models,
there is no distinction between a minor breach of security (e.g. a few
bits are leaked) and a complete loss of security (e.g. adversary gets
the secret key). In practice, implementers and users seem willing to
tolerate minor breaches. It would be great if we could reconcile the
recommendations derived from the theoretical results with actual
practice somehow.
I'd love to see that analysis published. As for use of such things within the IETF -- security is always a judgment call, trading off engineering and economic reality against the need for confidentiality/ integrity/availability. Often, the right answer for IETF purposes is to document the limitations of the chosen scheme in the Security Considerations section. of the RFC.
David
--Steve Bellovin, http://www.research.att.com/~smb
_______________________________________________ Cfrg mailing list Cfrg at ietf.org https://www1.ietf.org/mailman/listinfo/cfrg