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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Jul 2015 12:20:46 +0200

Hi all,

in the Internet of Things context there has been some excitement to use
short authentication tags with AES-128-CCM. With short range, low power
radio technologies shorter frame sizes raise concerns about the number
of bytes that are available to the application layer.

The DTLS/TLS profile for IoT document <draft-ietf-dice-profile>
therefore recommends the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ciphersuite,
following what the CoAP protocol and also Zigbee IP suggest.

When Stephen did a review of draft-ietf-dice-profile-13 he suggested to
rather focus on AES-128-CCM with the full-length authentication tag
instead. He motivates his suggestion based on the decision of the SRTP
guys to move away from short authentication tags used with AES-GCM-128.
Of course, AES-CCM and AES-GCM are different and attacks against AES-GCM
with short authentication tags have been published.

My question to this group is:

 * Are you aware of attacks against the AES-128-CCM-8?
 * Are there concerns with the use of short authentication tags, as we
recommend for the IoT context? (Needless to say that there is a tradeoff
between rekeying and the number of bits the tag has.)

Ciao
Hannes

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Jul 2015 06:40:33 -0700

> between rekeying and the number of bits the tag has.)

See Theorem 1 and 2 in
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/ccm-ad1.pdf. CCM
loses only the expected security as you shorten tags, and in
particular a single forgery does not enable more as with GCM.

Sincerely,
Watson Ladd

>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 22 Jul 2015 18:52:03 +0000

Another option that has been picked up by byte-senstive standards groups
is to use AES-SIV.  The IV and integrity check are combined saving overall
encapsulation size.  Also, AES-SIV has a significant advantage that it
does not require nonce/IV uniqueness.  Setup is simplified for a pair-wise
links.  Broadcast/multicast is viable without complex nonce coordination.

AES-128-SIV is a much better option for small messages than tweaking
AES-128-CCM.  

Paul

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 23 Jul 2015 15:36:57 +0200

> AES-128-SIV is a much better option for small messages than tweaking

FYI: I've an individual draft on AES-OCB. Rogaway filed an IPR exemption
today with IETF. OCB could be interesting for IoT stuff, but I guess CCM
is already used with some IEEE protocols.

https://datatracker.ietf.org/ipr/2640/
https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

(A similar exemption is pending from IBM, they assured me it's coming
though)

Aaron

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Jul 2015 10:51:12 -0400

> (A similar exemption is pending from IBM, they assured me it's coming

In the past, we have been told that Gligor (University of Maryland), Joux (IBM), and Rogaway all have patents that read on AES-OCB.  I have never heard anyone refute that.  So, it seems that two more IPR declarations are needed.

Russ

---

From: John Mattsson <[email-masked]>
Date: Thu, 23 Jul 2015 17:35:47 +0000

Hi,

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).

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.

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. Standardizing a new profile that will not work with DTLS
1.3 would be strange.

Cheers,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Jul 2015 20:31:50 +0000

> is already used with some IEEE protocols.

Thanks for following this down.

The IPR exemption is only for TLS, just as an FYI to others.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Jul 2015 09:04:55 +0200

> (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.

> technologies targeted by dice, I think that 64-bit tags are a reasonable

+1

> 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

---

From: John Mattsson <[email-masked]>
Date: Fri, 24 Jul 2015 09:22:46 +0000

>HTTPS) is probably already a good idea because of the 64-but

Correction: DTLS 1.3 will probably not forbid non-PFS _PSK_. My mistake, I
misheard Eric
Rescorla when he commented on my draft in the TLS wg. But moving to
ECDHE_PSK and PFS as
the general recommendation is definitely the right choice anyway...

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 24 Jul 2015 13:46:26 +0200

Hi Russ,

> In the past, we have been told that Gligor (University of Maryland), Joux (IBM), and Rogaway all have patents that read on AES-OCB.  I have never heard anyone refute that.  So, it seems that two mo…

I'm aware of the following patents:

Rogaway (multiple)
Juntla-Rabin/IBM (multiple)

To my knowledge it is unclear if Gligor has patents that actually relate
to OCB or not. Rogaway has included them though in his initial IPR
declarations for the general AES-OCB spec. document.

IPR:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-irtf-cfrg-ocb

Gilgor's patent:
https://www.google.com/patents/US6973187?dq=patent:6973187&hl=en&sa=X&ved=0CB0Q6AEwAGoVChMI2bnM5tfzxgIVhkAUCh3OzAt0

(Thus this patent expires in 2021)

I will try to follow up with Gilgor on that (haven't previously as I
assumed his patent is too general to have any impact on OCB. Rogaway
also didn't specifically point me to Gilgor).

Thanks,
Aaron

---

From: Russ Housley <[email-masked]>
Date: Fri, 24 Jul 2015 09:28:17 -0400

You are right, the three patents are from Gligor, Juntla (not Joux), and Rogaway.

Russ

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 24 Jul 2015 14:05:06 +0000

Hi

On 24/07/2015 14:28, "Cfrg on behalf of Russ Housley"
<[email-masked] on behalf of [email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>

And it's Jutla, not Juntla.

Cheers

Kenny 

>>> In the past, we have been told that Gligor (University of Maryland),
>>>Joux (IBM), and Rogaway all have patents that read on AES-OCB.  I have
>>>never heard anyone refute that.  So, it seems that two more IPR
>>>declarations are needed.
>> 
>>https://www.google.com/patents/US6973187?dq=patent:6973187&hl=en&sa=X&ved
>>=0CB0Q6AEwAGoVChMI2bnM5tfzxgIVhkAUCh3OzAt0
>> 
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>
>iEYEARECAAYFAlWyPXEACgkQiuTu0PWcEcsmKwCg6sJ3rnzvjzEF196wVbliRmiJ
>m/UAoNMTvX2vIIGgUuWT/oINUTRcZIF/
>=lzSI
>-----END PGP SIGNATURE-----
>

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Fri, 24 Jul 2015 14:38:25 +0000

Hi Hannes,

Hannes said:
> recommend for the IoT context? (Needless to say that there is a 
> tradeoff between rekeying and the number of bits the tag has.)

Watson said:
> See Theorem 1 and 2 in
> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/ccm-ad1.pdf. 
> CCM loses only the expected security as you shorten tags,  and in 

As Waston suggests, CCM is the best standard AEAD algorithm to use if you want to use short tags.  

Short authentication tags are acceptable when the effect of a successful forgery are well understood and are contained (and when the cryptographic algorithm does not suffer from repeat forgery attacks, as with GCM and many other universal hash based systems).   For instance, if the authenticated payload is compressed audio that will be decoded and played out during a fraction of a second, a small chance of forgery seems acceptable.   But if the effect of a successful forgery would be to cause the receiver/victim to store some forged long-term state, that would be a problem.   A good example of this sort of thing is desynchronization due to a forgery, or the classic "change the account number on the bank transaction".   In my opinion, whenever a standard decides to allow short authentication tags, it should explicitly describe the requirement that an application should be able to tolerate a limited number of forgeries.   Even if we all understand the issues, future adopters of the standard may not.

Best

David

---

From: Robert Cragie <[email-masked]>
Date: Fri, 24 Jul 2015 18:53:17 +0100

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

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 28 Jul 2015 11:26:55 -0700

Hi,

For short tags, it makes sense to consider algorithms where ciphertext modifications result in randomized plaintexts. In effect, the tag can be shorter, or the same length tag yields higher security compared to a counter mode based algorithm. For counter mode based algorithms, ciphertexts can be predictively modified, so a successful forgery can be much more damaging.

CMCC (http://eprint.iacr.org/2013/269) is one such algorithm (also see the Caesar competition). CMCC also handles plaintexts shorter than the block length without additional padding and is nonce misuse resistant.

Jonathan

--------------------------------------------
On Wed, 7/22/15, Hannes Tschofenig <[email-masked]> wrote:

 Subject: [Cfrg] Short Authentication Tags in AES-128-CCM
 To: "[email-masked]" <[email-masked]>
 Date: Wednesday, July 22, 2015, 3:20 AM
 
 Hi all,
 
 in the Internet of Things context there has been some
 excitement to use
 short authentication tags with AES-128-CCM. With short
 range, low power
 radio technologies shorter frame sizes raise concerns about
 the number
 of bytes that are available to the application layer.
 
 The DTLS/TLS profile for IoT document
 <draft-ietf-dice-profile>
 therefore recommends the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
 ciphersuite,
 following what the CoAP protocol and also Zigbee IP
 suggest.
 
 When Stephen did a review of draft-ietf-dice-profile-13 he
 suggested to
 rather focus on AES-128-CCM with the full-length
 authentication tag
 instead. He motivates his suggestion based on the decision
 of the SRTP
 guys to move away from short authentication tags used with
 AES-GCM-128.
 Of course, AES-CCM and AES-GCM are different and attacks
 against AES-GCM
 with short authentication tags have been published.

  * Are you aware of attacks against the AES-128-CCM-8?
  * Are there concerns with the use of short authentication
 tags, as we
 recommend for the IoT context? (Needless to say that there
 is a tradeoff
 between rekeying and the number of bits the tag has.)
 
 Ciao
 Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 31 Jul 2015 18:37:22 +0200

Hi John,

while this is a bit off-topic from my question I still wanted to comment
on this issue:

> supporting PSK. Standardizing a new profile that will not work with DTLS

The main reason for including a PSK ciphersuite was to include IoT
devices that have significant limitations regarding RAM, flash size, and
CPU performance. When you add ECDHE to the PSK ciphersuite all the
arguments for using PSK become much weaker or may even become invalid.

We also didn't want to create a dependency on a new ciphersuite spec
that has only been submitted recently. This would stall the document for
a while.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 31 Jul 2015 22:06:54 +0200

Hannes Tschofenig wrote:
> When you add ECDHE to the PSK ciphersuite all the

You use PSK between constrained devices because somebody else has done
the hard work.  That doesn't make forward secrecy superfluous.
If you have the means to do it (and the chips you are championing
generally do), do it.

> that has only been submitted recently. This would stall the document for

Absolutely; any ECDHE/PSK suite for constrained devices would come after
the profile (and possibly include a section to update the profile).

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 31 Jul 2015 22:30:04 +0200

Hi Carsten,

> If you have the means to do it (and the chips you are championing

I agree that you should use forward secrecy whenever you can. If you are
able to run ECDHE then I argue that you should which to a  ciphersuite
that does not use PSK at all (because of other benefits beyond forward
secrecy).

> the profile (and possibly include a section to update the profile).

Good that we agree on that aspect.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 31 Jul 2015 23:17:10 +0200

> that does not use PSK at all (because of other benefits beyond forward

It is well known that you believe that :-)
What makes a lot of sense in the browser web does not always fit the
thing-to-thing web.  But I think we are now solidly off-topic on the
CFRG list.

Grüße, Carsten