Re: [Cfrg] RE: Where's the beef?

[Alex Alten <[e-mail]>]

As usual David you are right.  I've met both Bart and Phil, of whom I
have the utmost respect.  And add people who came out of the networking
side like Radia Perlman or Charlie Kaufman.

But after many years of participating in or observing various IETF security
efforts, I've come to the conclusion that two important things are missing.

1. The lack of a system focus.  Creating a privacy protocol here and a
   key management protocol there ain't cutting it.  Protocols are actually
   only a minor part of a successful deployment. There has to be integration
   of many diverse parts, including key generation, how to handle enrollment
   & revocation, what should policy be, key escrow to meet export, law and
   privacy needs, auditing, recovery, error handling (esp. for key errors),
   etc.  To me the architecture RFC of IPsec was incomplete (not to mention
   a rather difficult read).

   A WG team should consist of small number of senior level engineers (with
   a gifted manager), most of whom should be strong in both protocol & crypto
   implementation experience, with the Phd's (both crypto and protocol)
   providing the specialized assistance. The closest WG group effort I've
   seen to date that seemed to do this well was the DNSSEC effort with
   Charlie in effect managing it.

2. The willingness to design custom crypto & taking the time to validate it.
   I've come to the conclusion that crypto pieces like SHA-1, AES or RSA are
   really designed to do tasks well that don't fit well with our needs.  For
   example, let's take SHA-1.  It is designed for very large messages of
   indeterminate length that may exist for decades.  Yet IPv4 is max 64 
   Kbytes, typically never exceeding 1500 bytes, and lasts on a LAN for less
   than 10 msec and across the Internet for probably less than 10 secs.
   Couldn't Bart design a hash for that completely different situation?

   Certainly we are all more than willing to design a custom protocol (e.g.
   IKE).  We need to also be willing to do the same with custom crypto (yes,
   I've heard the old, tired arguements against this, I ain't buying them
   anymore).  This I feel could be squarely in the baliwick of CFRG.

Respectfully,

- Alex



At 02:22 AM 8/31/2002 GMT, David Wagner wrote:
>Alex Alten  wrote:
>>Doing good analysis is hard work.  This is not
>>like publishing an analysis of something like WEP or SSL where you
>>could get great mileage out of the resulting publicity.  I'm talking
>>about doing this sort of work before publishing it.  The closest free
>>thing I can think of is the Twofish effort for NIST's AES.  But, again
>>there was prestige to be gained by the team for publishing even a runner
>>up design.  Here, most likely, a lot of RFCs will be rather obscure,
>>tucked away in some reference slot in a Standard RFC.  Are you willing
>>to do this heavy lifting, not for just one informational RFC, but say a
>>dozen or more?
>
>Yes, it's hard work.  Absolutely.  And not all good cryptographers
>will donate their time for free -- but some will.  Some contributors
>have been doing this for years.  Look at the IPSec effort, for instance:
>that's benefitted from some very serious, detailed analysis on the design
>from extremely competent crypto researchers, folks like Hugo Krawczyk
>and Bart Preneel and Ran Canetti and Steve Bellovin and Steve Kent and
>Cathy Meadows and Phil Rogaway and lots of other folks who I hope I'm not
>offending by cutting the list short here.  I mention IPSec only because
>it's a standards effort that I'm familiar with, but I think there is a
>good chance that CFRG can benefit in a similar way.
>
>You might only be familiar of the spectacular "breaks", because that's
>the most visible kind of research result, but there is also a lot of
>less visible work on under-the-covers preventative design, where folks
>donate their time to help nail down the details to maximize robustness.
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/cfrg
>
--

Alex Alten
[e-mail]

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