I think, Andrey makes a very important point here. The option to use 3DES
symmetric encryption, SHA1 digest and ZLIB compression must remain open until
a formal process of phasing them out is initiated, with a clear road map.
Right now, excluding these algorithms would break interoperability in a very
bad way, as described by Andrey.
Of course, SHA1 and 3DES are not without problems, but for most
security-critical applications they are still perfectly adequate.
Also note that prior to ECC, any symmetric cipher could have been matched
with any public key algorithm, because the secure block size for asymmetric
encryption algorithms (ElGamal and RSA) well exceeded the key sizes for
symmetric block ciphers. The encryption of session keys with random padding
has never been an issue. With ECC, this is no longer the case. For instance,
256-bit AES keys won't fit into one ECC ElGamal blocks, which are otherwise
reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit
curves are used.
Finally, I would like to draw the group's attention to a special need of
moblie communication, that seems not to receive due attention. While it is
true that computational power is less and less of an issue with mobile
phones (although there are still plenty of under-powered devices in use and
even in production), the message size issue is here to stay for much longer.
In GSM networks, which are by far the most common around the globe,
peer-to-peer messaging between handsets is done in 1120-bit chunks, for
which operators charge money. Using an RFC4880-compliant format, even the
shortest message using reasonably strong asymmetric encryption (1024-bit
RSA), requires two chunks, which cost exactly twice as much for the sender
(and in some North-American setups even the recipient) as a regular text
message. Short public key and encrypted session key sizes of ECC may
actually prove to be the primary driving force behind its adoptation in the
mobile world, even if Moore's law renders low computational costs
irrelevant.