Subject: Re: [Cfrg] Authenticated encryption primitive -- SOBER-128

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 11 May 2003 10:30:10 -0400

In message <[email-masked]>, Greg Rose writes
:

>
>For IETF use, obviously we need to write an RFC. I've never written an RFC 
>before (in fact, blush, have never been to an IETF meeting) and could use 
>some guidance on just how much information should be put in, and what 
>should happen to it then.
>

<chair hat=on>
As a matter of policy, the IETF does not standardize encryption 
algorithms.  We don't have the competence to analyze them, let alone 
develop or modify them.  In general, we pick algorithms that are the 
output of other groups that are qualified, such as NIST, NESSIE, or 
CRYPTOREC.

The IETF has published Informational RFCs describing ciphers and hash 
functions.  At this point, there's a strong preference for not 
publishing ones that aren't standardized by someone reputable, unless 
there's a very good reason.  We do like publishing RFC versions of 
standardized algorithms, because it makes them more accessible to the 
IETF community.

An RFC version should mostly be a precise specification of the 
algorithm, plus (if you want) any useful implementation hints.  It 
probably wouldn't include much of the justification and design 
criteria.  The Security Considerations section should outline what's 
known of the strength against various attacks; it should also give any 
non-obvious cautions and caveats.

The more interesting question is what it takes to incorporate a new 
algorithm into some security standard.  The current Security Area 
policy is to leave that up to the individual working groups; it's quite 
plausible that, say, TLS will standardize some algorithm while IPsec 
will not.  The rationale is simple:  the individual WGs have better 
knowledge of what fits into their frameworks, and what their market 
wants.  We do not require RFC versions of algorithm before using them 
in other standards, though it's helpful.  And an RFC is also useful for 
informing the IETF community of the algorithm and its properties.
</chair>

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

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

---

From: David Mcgrew <[email-masked]>
Date: Wed, 14 May 2003 12:06:23 -0700

Steve,

> >should happen to it then.

You mean area director, right?  ;-)

>output of other groups that are qualified, such as NIST, NESSIE, or

Yes, but CFRG is an IRTF group, not an IETF group.  As such, we can't 
standardize anything, but we can and should encourage crypto design work 
and its review and discussion.   We should make sure that the 
cryptographers understand the design requirements, facilitate security 
analysis, and make sure that practitioners understand the results of that 
analysis.

>standardized algorithms, because it makes them more accessible to the

We can't expect other groups to standardize crypto algorithms that will be 
useful for the Internet.  NIST has no plans to run another AES-like program 
(which is a shame, since it was well-done) and CRYPTREC and NESSIE are done 
accepting submissions.

Perhaps more importantly, there are requirements that are unmet and aren't 
being addressed.  The example of an RC4 replacement that can be used to 
protect packet-based protocols is an important one.   NESSIE did not 
address this problem in its initial call for submissions, though some of 
the submitted ciphers did.  As Greg points out, the desire of practitioners 
to use RC4 has caused many to use it improperly and thus stumble over its 
related-key weakness.  So while I would not want to take up crypto forum 
time discussing well-solved problems like 128-bit block cipher design, I'm 
happy to use this venue discussion of SOBER-128, its security, and the 
requirements that it aims to meet.

>non-obvious cautions and caveats.

Agreed, and I'd expect that discussion of an ID in CFRG would help to 
develop a strong Security Considerations section.

>informing the IETF community of the algorithm and its properties.

Agreed, this is a good process.

David