Re: [TLS] AES-CCM ECC Cipher Suites for TLS @ IETF 78

["Brian Smith" <[e-mail]>]

David McGrew wrote:
> I would like to request a time slot the TLS meeting at IETF78 to describe
"AES-
> CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- ecc-00, and how
it
> could be useful in TLS.  This work aims to provide a ciphersuite suitable
for
> compact implementations and use in bandwidth-challenged environments.  It
> was developed with input from the Zigbee Smart Energy 2.0 task group.
> 
> A related work-in-progress that I'd like to mention is "The Compressed
> X.509 Certificate Format", draft-pritikin-comp-x509-00, which is intended
for
> similar environments.  I can give a one-slide overview of this work and
how it
> relates.

Some TLS implementions (e.g. Microsoft, and soon OpenSSL and NSS) have
already shipped AES-GCM implementations, specialized CPU instructions for
AES-GCM seem to be on the verge of becoming ubiquitous on end-user systems
(e.g. Intel AES-NI), it is possible to build fast and constant-time AES-GCM
implementations with only SIMD instructions, and AES-GCM is or will be
required for some government applications of TLS (e.g. NSA Suite B profile
for TLS). So, I think every mainstream TLS implementation is going to
implement the AES-GCM cipher suites.

Basically the opposite of all that is true for CCM. So, what are CCM's
advantages over GCM and why can't/shouldn't devices implement the AES-GCM
cipher suites to enhance interoperability with mainstream TLS
implementations? I heard that CCM can be implemented in software with a
smaller number of opcodes, so that is one reason. But, how many fewer
opcodes does it need? Are you expecting that it will become commonplace for
mainstream (e.g. desktop, web server, mobile phone) TLS implementations to
support these CCM cipher suites?

Section 2 tries to impose restrictions on clients and servers which would
reduce interoperability. For example, "The client MUST NOT offer the
elliptic_curves extension nor the ec_point_formats extension.  The server
MUST NOT expect to receive those extensions." I guess this must be an
attempt to limit ECC patent exposure, but IMO that doesn't belong in the
document defining these cipher suites. Surely any TLS client that implements
these cipher suites and indicates support for curves the server supports
should work. After all, some other servers (that implement other
ciphersuites) might be able to use those extensions or even require them.

Why did you define new cipher suites instead of defining an extension like
the Truncated HMAC extension?

Regards,
Brian