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

From: [email-masked]
Date: Mon, 1 Nov 2004 19:14:21 +0200

Hi all,

While I fully agree with David, I want to remind of attacks like the one by Barkan, Biham and Keller on GSM presented at Crypto 2003. Just specifying a clean algorithm interface is not enough, since in practise the system has to continue supporting the old weaker algorithm to maintain interoperability with existing devices. 

The system security architecture must provide secure separation of different encryption algorithms. This means that under no circumstances a vulnerability in one algorithm can be exploited to break the second algorithm. For example, it shall not be possible to use the same encryption key for two different encryption algorithms. 

Best regards,
Kaisa 

Kaisa Nyberg
Nokia Research Center
Finland

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext David A. McGrew
> Sent: 01 November, 2004 16:13
> To: Alex Alten
> Cc: [email-masked]; Jeff Williams; [email-masked]; Steve Crocker
> Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> 
> 
> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/cfrg
> >
> > --
> >
> > Alex Alten
> > [email-masked]
> > (925) 425-9600
> >
> > _______________________________________________
> > saag mailing list
> > [email-masked]
> > https://jis.mit.edu/mailman/listinfo/saag
> >
> 
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/cfrg
> 

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Nov 2004 12:04:45 -0800

I will take a different position here:

1) There is no point in having the ability to use multiple algorithms unless
you have a fully thought out mechanism for a transition to a new algorithm
without a flag day on the installed base.

2) Since (1) is almost never acomplished most cases where multiple
algorithms are specified lead to a net loss of security.

This is not the only case where the ideology of security goes astray when it
meets reality unless the correct side conditions are also met. In theory
open source code should have less security bugs than closed. In practice
this is only the case if a) the open-ness of the code actually leads to
serious security review and 2) the bugs get fixed. The side conditions must
be met for the argument to hold.

I think that it would be good to have a set of generally understood status
levels for algorithms and a commonly agreed process for making and
withdrawing recommendations. I disagree with the notion that the best way to
achieve this would be to try to establish this in IETF process. While the
IETF would be a good place for such a process to end up I don't think that
there is any appetite for institutional innovation. We have been talking
about something of this sort for 5 years or so without anything ever
happening.

What I suggest is done instead is that the process be established outside
IETF process by an industry cabal. After running the process for some time,
getting the kinks worked out etc it would be turned over to some standards
body for ongoing mantenance as a turnkey operation.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 2 Nov 2004 17:04:31 -0800

> On Nov 1, 2004, at 8:09 PM, Hallam-Baker, Phillip wrote:
> 
> >> 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.
> >
> > I strongly disagree. History has showed that negotiation mechanisms
> > can lead
> >  to worse security problems than they are meant to address. 
> The IETF 
> > has
> >  certainly showed an exceptional ability to overcomplicate them.
> 
> Well. We disagree then.
> 
> The only history of negotiation failures that I have seen is the GSM 
> vulnerability where they put ECC under weak encryption and then used 
> that same key for high strength, cracked the key, spoofed a base 
> station, mounted a MIM attack and got in. Yes this is a protocol 
> vulnerability with 2 (Doh!) stupid crypto mistakes.

The IETF can start criticizing others for crypto errors after it delivers a
viable spec for ubiquitous IPSEC and DNSSEC. 

Failure to deliver a viable protocol after a decade renders the quality
somewhat meaningless.

> Keeping a protocol centered on the problem without the siren call of  
> "feature creep" is not easy. It is this creep of "just one 
> more feature 
> cuz its a simple tweak" that, when compounded created a 
> incomprehensible stew of incongruous kludges. 

Despite knowing rather more than the average user and several hours of
effort I am unable to get my WiFi card to talk to my main Wifi router with
crypto turned on. 

Apart from SSL I can't think of any IETF protocol that manages a better user
experience.

> Half of the IETF protocols are more complicated than the average IETF 
> protocol.

With the exception of SSL/TLS and WEP virtually all crypto protocols have
failled. WEP also had the minor inconvenience of not working but at least it
is used and the next version will be fixed.

> Well, maybe we strongly agree. What we need is an ability to add new 
> algorithms, remove bad algorithms with causing undue 
> complexity to the 
> user.

What we need is a plan to get people to use the stuff. Real people, not
geeks.

> 
> 
> > What we need is a policy layer for the whole application protocol 
> > layer  stack. It should not be part of the individual protocols, it 
> > should be part of the DNS.
> 
> This seems like a policy punt. what are you suggesting and why?

Nope, recognition of a shortcomming of the Internet architecture. A
principled policy architecture, not the usual punt.

---

From: Alex Alten <[email-masked]>
Date: Sun, 07 Nov 2004 18:01:48 -0800

At 05:09 PM 11/1/2004 -0800, Hallam-Baker, Phillip wrote:
> >1. _New_ protocols that are being design should include the ability to
> >negotiate algorithms. This is just good hygiene. If this is not
>I strongly disagree. History has showed that negotiation mechanisms can lead
>to worse security problems than they are meant to address. The IETF has

I agree with Phillip (sorry David McGrew).  It is bad enough to deal with 
keying
materials for one type of algorithm (say a cipher like AES), without having
to deal with all the headaches of dealing with two or more known algorithms
plus an unknown number of future algorithms.  Based on my own experience
plus witnessing other designs (like IPSec and ATM), when it comes to security
systems (or secure networks), simpler really is much better.

I think that the age of dealing with multiple ciphers is drawing to a 
close. Unless
I'm greatly mistaken, AES should be sufficient for just about anything, 
probably
for the next 50 years.  One could put a flag in for the encryption 
algorithm just
in case an upgrade is needed in 2054.

However, the same probably can't yet be said of hashes.

- Alex

--

Alex Alten
[email-masked]