[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Steve,

At 10:30 AM 5/11/2003 -0400, Steven M. Bellovin wrote:
In message <5.1.0.14.2.20030507005709.02b0a988@203.30.171.17>, 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>
You mean area director, right?  ;-)


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


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


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.
Agreed, and I'd expect that discussion of an ID in CFRG would help to develop a strong Security Considerations section.


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>

Agreed, this is a good process.

David




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


_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg