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

I agree with all Carsten's points below. Regarding CMAC - I haven't found a
case where we can totally eliminate the use of HMAC-SHA256 for one reason
or another but that is possibly a goal to work towards.

Robert

On 24 July 2015 at 08:04, Carsten Bormann <cabo@tzi.org> wrote:

> > 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
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>