Open pkelsey opened 1 month ago
Actually, we can fix this in 8446-bis.
@ilaril can you double check this before we change it?
The budget calculation in #964 forgot to account overheads from SHA-256 itself, and is thus off by 9 bytes. The issue mentions ML discussion and there is corrected calculation in ML messages.
The maximum Label (i.e., not including the "tls13 " prefix) length that avoids extra block in Derive-Secret is indeed 12 bytes. In this case, the layout of the inner HMAC input is:
This fills 2 SHA-256 blocks (128 bytes), which is the minimum possible for HKDF-SHA256-Expand.
The note is somewhat confusing tho:
Checking other hash functions used by various cipher suites (SHA-384, SHA-512, GOST R 34.11-2012, and SM3) all seem to be able to accommodate 12 byte Label without extra block.
Agreed, I neglected the SHA-256 pad and length trailer when checking the original budget calc in #964, and was thrown by the coincidental arithmetic in "TLS1.3, " (9) + "tls ..." (18) -> "tls13 " (6) + published limit (12).
This is editorial, and the doc is somewhere between done and published, but it's haunting my notes...
In 7.1, "any label longer than 12 characters" should be "any label longer than 21 characters".
This off-by-nine appears to be due to something getting lost in the wash during #964 between @ilaril's budget calculation, @ekr's post of the new set of "tls13 ..." labels, and subsequent removal of "tls13 " from those label names to replace the "TLS1.3, " in HkdfLabel.