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

From: Jeff Williams <[email-masked]>
Date: Thu, 28 Oct 2004 14:22:34 -0700

Steve and all,

  Again we disagree in your conclusion here Steve.  Of course we
have been over this ground before.  Changing or introducing new
crypto algorithm's in no way should impede or prevent interoerability
and interface facilities now available can and do address this issue.

Steve Crocker wrote:

> No matter what algorithms we choose today, it's likely that changes will
> be required in the future.  Let me strengthen Ran's suggestion.  In
> addition to building algorithm-independent protocols, the protocols
> should also include an upgrade mechanism for changing algorithms in an
> orderly way.  It's not good enough to say protocol FOO is independent of
> algorithm if all of the initial deployment depends on crypto algorithm
> SNARF and there's no way to introduce new crypto algorithm FARNS without
> breaking interoperability.
>
> Steve
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of RJ Atkinson
> > Sent: Thursday, October 28, 2004 8:49 AM
> > To: David A. McGrew
> > Cc: [email-masked]; [email-masked]
> > Subject: [saag] Re: universal MACs
> >
> >
> > David,
> >
> > My protocol preference in an IETF context is for
> > algorithm-independent
> > protocols,
> > so that one does not need to change the protocol to add support for
> > additional
> > algorithms in future.  This property holds for at least OSPFv2
> > authentication and
> > RIPv2 authentication (and yes, I am working on documentation
> > updates to
> > each
> > of those specifications to document how SHA-1 and its relatives are
> > implemented).
> >
> > My algorithm preference in an IETF context is for algorithms that are
> > acceptable
> > to the largest number of end users.  Right now, many
> > governments (from
> > multiple
> > governments, including several in Europe and several in Asia,
> > NOT just
> > the US)
> > and many non-governmental customers are insisting upon the same
> > algorithm set,
> > which is the set of currently NIST-approved algorithms and
> > modes.  This
> > set of
> > algorithms appears to be the preferred set of algorithms and modes
> > right now --
> > by a VERY wide margin.
> >
> > In practice, that means there is a strong buyer preference from many
> > countries
> > for SHA-1 (and its NIST-documented relatives) and for AES (in
> > NIST-acceptable
> > modes).  Several countries, including several in Europe and
> > several in
> > Asia, are
> > also insisting that cryptographic products they buy have NIST FIPS
> > 140-2 approvals.
> > This also tends to reinforce the selection of algorithms and modes
> > since only the
> > NIST-approved algorithms and modes can get a FIPS 140-2 approval.
> >
> > I would even suggest that for the moment, any new security protocols
> > developed
> > in an IETF context ought to include documentation on how
> > NIST-approved
> > algorithms
> > and modes are used with those protocols -- even if the IETF were to
> > decide that
> > it preferred some non-NIST algorithm or mode for a particular
> > security
> > protocol
> > as the "default" algorithm/mode choice.
> >
> > Yours,
> >
> > Ran Atkinson
> > [email-masked]
> >
> > PS:  Nitpickers should please note well that all of my comments above
> > are about
> > the end-user/marketplace desires, and there is no comment above about
> > the quality
> > of any particular algorithm or mode.
> >
> >
> > On Oct 28, 2004, at 07:51, David A. McGrew wrote:
> > >     I suspect that the group preference would be towards hash
> > > functions that are portable (e.g. fast on a wide variety of
> > CPUs) and
> > > that require minimal per-key state.  There may be other points of
> > > view; others please chime in if you have other priorities.
> > >
> > > David
> >
> > _______________________________________________
> > saag mailing list
> > [email-masked]
> > https://jis.mit.edu/mailman/listinfo/saag
> >
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

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

---

From: Alex Alten <[email-masked]>
Date: Fri, 29 Oct 2004 06:23:40 -0700

All,

Let me point out as an example that the automated teller machines (ATMs) 
security
protocol has been using the same algorithm with DES since about 1982.  Making
protocols algorithm independent (with extra handshakes and upgrade mechanisms)
has the side effect of making them very complex and thus harder to certify for
interoperability, optimize for performance, etc.

- Alex

--

Alex Alten
[email-masked]
(925) 425-9600

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 31 Oct 2004 09:24:42 -0500

On Oct 29, 2004, at 09:23, Alex Alten wrote:
> Let me point out as an example that the automated teller machines 
> (ATMs) security

I am not at all persuaded that making protocols algorithm-independent 
necessarily
has the side effect of making them more complex or harder to certify or 
harder to
performance optimise.  I've seen a lot of protocols that were not 
algorithm-independent
that *were* astonishingly complex, so the inverse is also not obvious 
to me.

Ran
[email-masked]

---

From: Jeff Williams <[email-masked]>
Date: Sun, 31 Oct 2004 20:31:52 -0800

RJ and all,

> that *were* astonishingly complex, so the inverse is also not obvious

  We have similar experiences it seems.  So I entirely agree with you
here.  And as such, why I still believe that interface facilities for
multi-algorithm's is a far better approach.  But convincing
Steve and others on this seems to be improbable even though
such is being done and has been for several years.  Perhaps this
"Dates" Steve and those of his mindset.

Regards,