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

[James Hughes <James_Hughes at StorageTek.com>]

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: 	  Matthew_Chalmers at bankone.com
	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:
>  > > 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
>  >
>  > 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.
>
>   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.
>
> >
>  >
>  > Ran
>  > rja at extremenetworks.com
>
> 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 jwkckid1 at ix.netcom.com
>  Registered Email addr with the USPS
> Contact Number: 214-244-4827
>
>
>
> _______________________________________________
> saag mailing list
>  saag at mit.edu
> https://jis.mit.edu/mailman/listinfo/saag


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