Subject: [Cfrg] Re: [saag] Algorithm recommendations

From: "David A. McGrew" <[email-masked]>
Date: Fri, 24 Sep 2004 12:23:03 -0700

Steve,

On Sep 22, 2004, at 6:52 AM, Steven M. Bellovin wrote:

> In message <[email-masked]>, "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.")

good, this sounds like the right process.  What I was wondering about 
is the question of what happens to existing RFCs that contain Category 
3 algorithms but do not meet the requirement of having a MUST IMPLEMENT 
Category 1 algorithm.  This question is something of a nit, but it 
probably ought to be addressed.  There will be RFCs that fall into this 
category (I think; Hilarie is the one who did the study of RFCs, so she 
will know), and it would be good to clear up what their status is in 
the text.

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

Thanks for your encouragement here.  I do not have anything that is 
written up well enough to contribute publicly; not yet anyway.  As Hugo 
suggested, it is probably a good topic for CFRG as well.

David

>
> 		--Steve Bellovin, http://www.research.att.com/~smb
>
>

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 24 Sep 2004 16:15:45 -0400

In message <[email-masked]>, "David A. McGrew" 

>will know), and it would be good to clear up what their status is in 
Just as a matter of process, amending an old standards-track RFC's
requirements would require a new RFC.  As a matter of practice, we're 
not likely to suddenly reclassify such protocols as "Historic", but if 
there are crucial weaknesses the IESG would likely try to get a 
revision or a supplement done fairly promptly.

Let's get the data first; we can then look at things, one protocol at a 
time, and figure out what to do.  (To simplify things in terms of 
process, the current philosophy is that crypto algorithms should be in 
a separate RFC that can be changed more easily than, and independent 
of, the base spec.  In most cases, that's what would be done for any 
revisions necessitated by this work.)