[Lake] Discussion on IoT AEAD limits for AES_128_CCM_8

[John Mattsson <[e-mail]>]

Hi,

As discussed during the meeting today, CFRG is working on an excellent document specifying equations to calculate AEAD limits for the number of encryption operations q and the number of forgery attempts v. TLS, DTLS, and QUIC have adopted strict limits based on these equations. Having strict limits is not a problem if re-keying is easy.

https://tools.ietf.org/html/draft-irtf-cfrg-aead-limits

Most constrained IoT systems today use some variant of AES-128 in CCM mode with a 32- or 64-bit tag. IETF use of AES-128 in CCM mode typically only use 64-bit tags.

The important equations for AEAD_AES_128_CCM_8 (AES-CCM-16-64-128, AES-CCM-64-64-128) are:

Confidentiality Limit:
q <= sqrt((p * 2^126) / l^2)

Integrity Limit:
v * 2^64 + (2l * (v + q))^2 <= p * 2^128

where:

q = Number of protected messages (AEAD encryption invocations)
v = Number of attacker forgery attempts (failed AEAD decryption invocations)    
p = Adversary attack probability
l = input length (plaintext + additional data) in blocks

For AEAD_AES_128_CCM_8 the integrity limit is the most limiting. DTLS 1.3 sets the limits for CCM to q = 2^23 and v = 2^23.5 and states that AES_128_CCM_8 MUST NOT used in DTLS without additional safeguards against forgery. This unfortunately severely limits the use case for DTLS 1.3 in very constrained IoT.

The assumptions used DTLS 1.3 (still a draft) are:

p = 2^-57
l = 2^10 (2^14 bytes)

It should be discussed which assumptions are relevant for IoT systems. It was suggested during the meeting today that this discussion should be held in a IoT focused security area WG like LAKE. There are a large number of aspects that affect how the limits v and q should be assigned:

- The probability p can be set to basically any value, it decides the security level. Some IoT systems might accept a higher forgery probability that (D)TLS in general.

- To optimize the forgery probablity the attacker cannot send a chosen message, the attacker has to settle for something that looks like a random string. For use cases where the payload has a certain format, this means that succesfull forgeries will likely be discarded on a higher level in the stack.

- The forgery probability is for a single forgery. In some systems a single forgery may not matter much and several forgeries might be needed to do any harm.

- The input lengths are typically much much smaller for most constrained IoT systems than the 16 KB packets assumed in the (D)TLS calculations.

- If the attacker uses a high speed broadband connection, a lot of forgeries can be sent quickly. On most constained IoT systems, the bandwith is very limited and it would take takes a long time to send forged message.

- Any denial-of-service resulting from low limits on v should be compared to other denial-of-service attacks on the system. If there are even easier ways to reduce the availability of a system, a low limit on v does not matter.

Looking forward to hear the IETF IoT communities comments on the above.

Cheers,
John