Subject: apples-to-apples

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Apr 2001 12:37:53 +0100

Hi Tom,

I guess this is more a comment on the matrix presented than on the
minutes. (Correct me quickly if I'm wrong.)

In order to compare apples-to-apples, would you care to provide a 
matrix that would allow a fair comparison? And maybe even fill it
in too? Probably best as just a mail to the list for now, at some
point it might be worthwhile turning this into an I-D so's we keep
a record. 

Regards,
Stephen.

Tom Wu wrote:
> 
> If we're going to compare apples-to-apples, we should agree to be
> consistent and describe protocols either in terms of "number of
> roundtrips" or "number of messages", instead of the current mix.  I
> still feel ease-of-implementation is a differentiator for implementors;
> not all the protocols are equal in terms of amount of existing code
> available or amount of standardization, and that should be accurately
> expressed.
> 
> Ideally, the paragraph about "unnecessary overhead" should be eliminated
> as redundant, since that "overhead" is precisely the extra round trip
> that is described in the previous paragraph.
> 
> I agree with Radia's suggestion on the removal of OTP, unless someone
> can successfully argue for its continued inclusion.
> 
> Tom
> 
> "Linn, John" wrote:
> >
> > For minutes purposes, I've now converged to the following draft pair of
> > paragraphs. Is this generally acceptable?
> >
> > Magnus presented a table comparing the alternatives relative to four
> > metrics: client CPU requirements, number of communications roundtrips, level
> > of security, and ease of implementation. Each of DH-EKE, SPEKE, and SRP were
> > considered as neutral in terms of all of these areas. In discussion, PDM was
> > considered weaker in terms of client CPU requirements, but better in terms
> > of server CPU requirements than EKE, SPEKE, or SRP, assuming use of a
> > shorter modulus for PDM. PDM can be done in one round trip with stateless
> > server operation, whereas SRP and the versions of EKE and SPEKE augmented
> > not to require storing a password-equivalent at the server requires a
> > 4-message exchange. OTP was considered stronger in terms of client CPU
> > requirements, numbers of roundtrips, and ease of implementation, but weaker
> > in security.
> >
> > Radia Perlman (Sun) argued that DH-EKE's and SPEKE's augmented modes, which
> > avoid storage of password-equivalent data at servers, incur overhead that is
> > unnecessary in the SACRED application. She noted, further, that this
> > overhead is intrinsic to SRP.  Stephen Farrell asked whether the WG should
> > concentrate on one of the first four, or instead emphasize OTP schemes,
> > noting that (unlike the other approaches) OTP doesn't generate a key or
> > authenticate the server.  Tim Polk (NIST) commented that it didn't appear
> > that requirements had been agreed sufficiently to support selection of an
> > algorithm.  A straw poll was taken on algorithm selection, but its results
> > were inconclusive.  The question will be revisited on the mailing list.
> >
> > --jl
> 
> --
> Tom Wu
> Principal Software Engineer
> Arcot Systems
> (408) 969-6124
> "The Borg?  Sounds Swedish..."

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com