Re: [Cfrg] Short Authentication Tags in AES-128-CCM

[Carsten Bormann <[e-mail]>]

> Avtcore/IESG decided to not standardize CCM_8 and GCM_8, but for different
> reasons. CCM (all tag lengths) was removed as Stephen wanted to limit the
> number of algorithms, and nobody expressed any imminent plans to implement
> SRTP with CCM. GCM_8 was removed because of the theoretical weaknesses
> with GCM and short tags (summarized in https://eprint.iacr.org/2015/477)
> and their applicability to SRTP
> (https://mailarchive.ietf.org/arch/msg/avt/cKHmfai2SISd7itL_NlgXRJUPow).

Right, SRTP applications typically don't run in the hardware/software
environments described by RFC 7228, so there is little reason to have
CCM-based cipher suites around.

> I am not aware of any weaknesses with CCM_8 that depends on the tag
> length, except the general weakness that the forgery probability is the
> expected 2^-64. In his recent evaluation for Cryptec
> (http://www.cryptrec.go.jp/estimation/techrep_id2012_2.pdf), Rogaway
> states as one of the conclusions “CCM achieves good provable-security
> results, even with truncated tags” Given the constrained radio
> technologies targeted by dice, I think that 64-bit tags are a reasonable
> tradeoff.

+1

> Looking at the dice profile, I am more concerned with the lack of forward
> security in TLS_PSK_WITH_AES_128_CCM_8 and the fact that this cipher suite
> will likely be forbidden in DTLS 1.3 (as far as I understand). I would
> recommend changing this to ECDHE_PSK, or convincing the TLS wg to continue
> supporting PSK. 

Actually, we should move to ECDHE_PSK...CCM_8 as our default profile,
but there is still a set of applications where
TLS_PSK_WITH_AES_128_CCM_8 is a perfect fit. Qualifying this cipher
suite as a special-use one (don't put it into your Web browser for
HTTPS) is probably already a good idea because of the 64-but authenticator.

(One question that is lurking in my mind is whether we should be moving
to CMAC for the MAC part that is CBC-MAC in CCM.  That might be worth it
for the ECDHE version, but probably not for the basic PSK.)

> Standardizing a new profile that will not work with DTLS
> 1.3 would be strange

Indeed.

Grüße, Carsten