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

From: RJ Atkinson <[email-masked]>
Date: Mon, 1 Nov 2004 08:15:52 -0500

On Oct 31, 2004, at 23:31, Jeff Williams wrote:
>   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.

Jeff,

	Perhaps you might not have read my words carefully enough.
I fully agree with Steve Crocker.  And I am utterly bafffled as to how
anyone could misread my written words as disagreeing with Steve Crocker.

Yours,

Ran
[email-masked]

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

---

From: "David A. McGrew" <[email-masked]>
Date: Mon, 1 Nov 2004 06:12:47 -0800

Alex,

On Oct 29, 2004, at 6:23 AM, Alex Alten wrote:

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

I respectfully disagree.  Modern systems and protocols need to have the 
ability to utilize different crypto algorithms.  Otherwise, how can a 
deficient algorithm be replaced?  Consider the complexity of taking a 
legacy system in which the algorithms have been hard-wired and then 
trying to remove a deficient algorithm and replace it with a better 
one.

OTOH, I do think that we could do a better job of making the crypto 
easy to upgrade.  If there were a well defined, clean and simple 
interface to the crypto functions, and crypto functions were defined to 
match that interface, adoption would be easier.  One research paper 
that goes in this direction (but does not formally define an interface) 
is: Mihir Bellare and Tadayoshi Kohno and Chanathip Namprempre, 
Breaking and Provably Repairing the SSH Authenticated Encryption 
Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm, To 
appear in ACM Transactions on Information and System Security, ACM, 
2004. An extended abstract of this paper appeared in Ninth ACM 
Conference on Computer and Communications Security, ACM, 2002. 
http://eprint.iacr.org/2002/078/

David

>
> - Alex
>
> At 02:22 PM 10/28/2004 -0700, Jeff Williams wrote:
>> 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
>>
>>
>>
> --
> Alex Alten
> [email-masked]
> (925) 425-9600
>
> saag mailing list
> [email-masked]
> https://jis.mit.edu/mailman/listinfo/saag
>

---

From: James Hughes <[email-masked]>
Date: Mon, 1 Nov 2004 08:41:55 -0500

As an outsider I can see that there are politics and charged words 
here, but I can not understand them. So being the naive person that I 
am, I will respond to the literal words presented here and merrily step 
onto the well trodden land mines. If these things are obvious and 
already decided my apologies for wasting bandwidth.

My comment is this. In the case of backstitching algorithm independence 
into existing (especially non IETF) protocols is not what I would even 
contemplate. To any standards group, I would suggest taking the long 
term approach to solving this. Specifically the following two 
statements would be enough.

1. _New_ protocols that are being design should include the ability to 
negotiate algorithms. This is just good hygiene. If this is not 
formalized, it should be.

2. _Old_ non-negotiating IETF protocols that use obsolete or 
depreciated algorithms should be (formally?) put "on notice" that their 
_security_ should be addressed (not necessarily the protocol). This is 
not a panic, but it should not be tossed under the rug either. If they 
have a coming protocol upgrade planned, add algorithm negotiation. If 
they don't, maybe they can start a protocol upgrade wish-list so that 
the issue doesn't die. Otherwise do something, anything. The option of 
doing nothing is the only thing they shouldn't do.

If they (the standards group that standardizes ATM protocols) wants to 
have a "flag day" upgrade philosophy, or a wholesale replacement 
strategy, that's their choice. If I were a member of that group, I 
would argue for putting protocol upgrades into the long term roadmap so 
that protocol negotiation would get there someday. I believe it is a 
prudent measures to avoid another WEP fiasco.

Complexity should not a roadblock to security. Security is just another 
requirement like reliability and scalability. Reining in complexity 
should already be the responsibility of the workgroup regardless of 
why.

Protocols that do not do upgrade run the risk of being obsoleted in 
their entirety. Case in point, rlogin, telnet, etc. are dead (or should 
be).

I use the definition of "Obsolete or Depreciated" from:
	From: 	  [email-masked]
	Subject: 	RE: [Cfrg] Re: [saag] Bad day at the hash function factory
	Date: 	August 26, 2004 3:27:49 PM EDT

jim

On Oct 31, 2004, at 11:31 PM, Jeff Williams wrote:

> RJ and all,
>
> RJ Atkinson wrote:
>
> > On Oct 29, 2004, at 09:23, Alex Alten wrote:
>  > 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.
>

---

From: Jeff Williams <[email-masked]>
Date: Mon, 01 Nov 2004 23:31:10 -0800

RJ and all,

> anyone could misread my written words as disagreeing with Steve Crocker.

  If you say so.  However I still do not agree with Steve and if you had
read my response in it's entirety,  you would have taken noticed exactly
where and why I do not, yet also can agree with your previous response
on this thread which you seemed to have snipped for some odd reason...

Regards,

---

From: Jeff Williams <[email-masked]>
Date: Mon, 01 Nov 2004 23:41:56 -0800

David and all,

  Thank you David for applying some common sense here.  Legacy
based or legacy methods are long out of date and do not or cannot
address the needs and demands of the marketplace.  Yet it is being
broader understood that some standards organization suffer from
an over familiarity with legacy y methods and will defend those methods
very strongly to the point of a religious fever...

Regards,