Re: [Lake] Discussion on IoT AEAD limits for AES_128_CCM_8

[Martin Thomson <[e-mail]>]

You might find this tool useful in evaluating this:

https://chris-wood.github.io/interactive-aead-limits/

Note that with the value of p that TLS uses (2^-57), this cipher performs very badly.  The number of forgery attempts you can tolerate is 128.  That's not 2^128, it's 128.  I don't think that is acceptable.  You might be able to increase your tolerance for attack (p) to get something more realistic.

On Tue, Nov 17, 2020, at 02:17, John Mattsson wrote:
> 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
> 
> -- 
> Lake mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lake
>