diff --git a/draft-ietf-core-oscore-key-limits.html b/draft-ietf-core-oscore-key-limits.html index 0703043..860b308 100644 --- a/draft-ietf-core-oscore-key-limits.html +++ b/draft-ietf-core-oscore-key-limits.html @@ -1335,7 +1335,7 @@

Maximum length of each message (in bytes) -

With regards to the limit for 'l', the recommended 'l' value for the algorithms shown in Figure 1, and for AEAD_AES_128_CCM_8, is 2^10 (16384 bytes) and 2^8 (4096 bytes) respectively. Considering that a typical MTU size is 1500 bytes, and the fact that the maximum block size when using block-wise transfers with CoAP is 1024 bytes (see Section 2 of [RFC7959]), it is unlikely that a larger size of 'l' than what is recommended makes sense to use in typical network setups.

+

With regards to the limit for 'l', the recommended 'l' value for the algorithms shown in Figure 1, and for AEAD_AES_128_CCM_8, is 2^10 (16384 bytes) and 2^8 (4096 bytes) respectively. Considering a typical MTU size of 1500 bytes, and the fact that the maximum block size when using block-wise transfers with CoAP is 1024 bytes (see Section 2 of [RFC7959]), it is unlikely that a larger size of 'l' than what is recommended makes sense to use in typical network setups.

However, although under typical circumstances an 'l' limit of 2^8 (4096 bytes) is acceptable, exceptional cases can warrant a higher value of 'l'. For instance, Block-wise Extension for Reliable Transport (BERT) extends the CoAP Block-Wise tranfer functionality, enabling use of larger messages over reliable transports such as TCP or WebSockets (see [RFC8323]). In case the OSCORE peers wish to take advantage of BERT functionality it becomes essential to opt for a higher value of 'l'. Thus accommodating the larger data chunks that can be used for BERT Block-Wise transfers.

An alternative means of allowing for larger values of 'l', while still maintaining the security properties of the used AEAD algorithm, is to adjust the 'q' and 'v' values to compensate. In practice, this means reducing the size of 'q' and 'v', considering the new value of 'l', to ensure an acceptably low value of the IA and CA probabilities. A reasonable target for the IA and CA probabilities values is the threshold value of 2^-50 defined in [I-D.irtf-cfrg-aead-limits].

diff --git a/draft-ietf-core-oscore-key-limits.txt b/draft-ietf-core-oscore-key-limits.txt index dd280a2..f69c670 100644 --- a/draft-ietf-core-oscore-key-limits.txt +++ b/draft-ietf-core-oscore-key-limits.txt @@ -242,8 +242,8 @@ Table of Contents With regards to the limit for 'l', the recommended 'l' value for the algorithms shown in Figure 1, and for AEAD_AES_128_CCM_8, is 2^10 - (16384 bytes) and 2^8 (4096 bytes) respectively. Considering that a - typical MTU size is 1500 bytes, and the fact that the maximum block + (16384 bytes) and 2^8 (4096 bytes) respectively. Considering a + typical MTU size of 1500 bytes, and the fact that the maximum block size when using block-wise transfers with CoAP is 1024 bytes (see Section 2 of [RFC7959]), it is unlikely that a larger size of 'l' than what is recommended makes sense to use in typical network